Fwd: Product management processes in OSGeo projects

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

Fwd: Product management processes in OSGeo projects

Andreas Neumann-3
Hi,

Steven Feldman conducted a survey on product management processes in OSGeo projects. The results will be presented at the FOSS4G in Bukarest.

In agreement with Paolo, I participated on behalf of QGIS.ORG to submit and explain the current situation of QGIS.ORG in this aspect.

I am forwarding the questionnaire and my replies for your review. If you find something wrong in my statements or if I missed something substantial, please speak up and I will send Steven a corrected version.

Thanks and greetings,
Andreas 

---------- Forwarded message ---------
From: Google Forms <[hidden email]>
Date: Sun, 9 Jun 2019 at 12:54
Subject: Product management processes in OSGeo projects
To: <[hidden email]>


Google Forms
Here's what we got from you:

Product management processes in OSGeo projects

Thank you for agreeing to help me in researching product management processes in OSGeo projects. My aim is to try and establish:

• Does the Open Source collaborative development model incorporate and support product management disciplines?
• Are there formal product management strategies within the OSGeo Community?
• How is a roadmap developed?
• Is the roadmap inspired by a cohesive vision or is it driven by the willingness of larger users to fund features?
• How do projects get to hear the voice of the user?
• Do software development methodologies impact product management?
• Are there best practices that we can learn from and share?

Following on from this survey I plan to contact some (most) of the respondents and if you are available conduct a short interview with you via a call or by email.

It would be great if you could complete this survey by 3rd June 2019.

I hope to present the results of this research at FOSS4G at the end of the summer, I will also write up the results and share with our community and others. Subject to timing I will make an early version of my presentation/write up available to respondents for comment before publication.

Thanks once again for your help

May the FOSS be with you

Steven


A bit about you and your project

If you think someone else on your project steering team should be completing this survey as well as or instead of you please forward the survey to them

Andreas Neumann

QGIS

PSC and board member

13 years, but only 4 years on PSC/board



Product management processes

I have set out a series of questions below that will help me to understand how your project sets goals, converts them to a roadmap and then prioritises features. It will make collating your response easier if you can respond to these questions but if you find that too tedious or if your responses don't fit with the structure of my questions then I have given you the option of including a long form text answer at the end of the questionnaire.

Vision and Goals

Has your project set out a vision and a set of goals that drive the roadmap?




No official vision yet - but that reminds me that we should come up with one and publish it. Here is one proposal (just formulated by myself and not discussed yet with the PSC. ): To make GIS available and affordable to anyone who is interested in using GIS, regardless of the budget and resources they have at hand. To be a user friendly GIS for Desktop, Server and Mobile. To be available for many platforms (Linux, Mac, Windows, Android). Road Map and new features to be defined by active users, funders and devlopers (bottom up and not top down). Note that this not the official vision - just my proposal from myself and not yet discussed and sanctioned by the PSC and voting members. I will start a discussion to come up with a vision and goals.

Roadmap

How do you establish and maintain the roadmap for your project?




Feature prioritisation

How do you prioritise features within the next release(s) of your project?

There is no differentiation between features that are sponsored and features that are developed and submitted from volunteers. Because our road map is strictly time-based and not feature based (we don't communicate or promise any new features in advance) there is also no top-down prioritization done by the PSC. It is really the developers who decide when something is ready to be released and it is also the developers who prioritize their work by themselves. If a customer of a QGIS developer comes up with a new feature and new requirements, they can consult the road map with the time line and discuss with their developer to find out what release date can be realistically targeted, taking into account time for preparation, discussion of QEP (QGIS enhancement proposal), development time, testing and bug fixing.


Requirements Capture

How do you capture and document requirements within your project?


I can't describe our product management process by responding to your questions!

This is the pint where you can just write whatever you wish about the product management processes in your project and include answers to the questions that I have neglected to ask!

It was a very good decision to introduce a strictly time-based road map for QGIS and don't wait for specific features to be ready until we release the upcoming version. Before that switch to a time-based release schedule we had endless discussions when a new release would be ready or not. The only exception is when we do a new major release that is dependent on major technological changes, such as the change from QGIS 1 to 2, or 2 to 3, where a lot of technical changes happened under the hood (e.g. switching qt version or Python version, API changes, etc.). In such a major change everything has to work as expected and it is very hard to predict when everything is ready. The other convention we have is, that during a major release cycle, the API has to remain stable. API changes are only allowed when a new major QGIS version is prepared. We often work as a "do-ocracy". Many tasks and development work are picked up by contributors or developers as they see the need and can contribute resources. Coordination happens on regular PSC meetings (monthly), bi-annual developer meetings and through Github and mailing lists or on IRC. The "bottom up" process regarding new features and their prioritization usually works fine for us currently - it gives the users/funders/developers a lot of freedom to decide when something can get into a future QGIS version. They are not at the mercy of a product management team or of the PSC who would decide on what gets into QGIS or not. So the power is at the users/funders and developers and not with the PSC and board. Should something really controversial come up during the process, we have an established voting system consisting of community voting members, user groups voting members and an OSGEO representative. We don't / can't work like a classical software company, because QGIS developers are not the employees of QGIS.ORG, but are individual developers, volunteers or employees from support and development companies who work independent of QGIS.ORG, but collaborate under the umbrella of QGIS.ORG. In this setup of our organization we can't dictate or enforce rules and decisions on our contributors and developers but have to work out compromises and convince the contributors to accept the proposals by the community, PSC and board. TODO: QGIS as a project certainly has some weak points we should improve in our organization and release process and project management. We should come up with a common and clear vision. Quality assurance is always a challenge and most of our donations and sustaining membership contributions go into bug fixing and improving our code quality and testing.

The last bit

A few questions about the organisation of product management within your project, your analysis of your competitors and your communications with your users.



If our contributors and funders think that some competitor project/product offers something we don't have, or does something than we do, they can bring ideas to the table and if it is important to them, they will invest (time and/or financial resources) to add these missing pieces or improve our software and project.

Yes, definitely. We have votes on QGIS grant proposals and with their investments (time and money) they can decide what gets into QGIS or not.


Create your own Google Form


--

--
Andreas Neumann
QGIS.ORG board member (treasurer)

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

Re: Fwd: Product management processes in OSGeo projects

pcav
Hi Andreas,
thanks for dealing with this.
I'm happy with your replies. Just a few comments:
* I think we do collect some usage metrics (volume of downloads on
cloudflare, hits on versions.txt, number of plugin downloads, etc.),
although I agree that none of them is sensu stricto a measure, rather an
estimate
* I can't read your replies on Roadmap, Requirements capture (Other) in
its entirety
* I think it is fair to say that we do manage our roadmap by open and
public discussion on our mailing list and PSC meetings
* I find your TODO a bit pessimistic, I believe we have to be very proud
of what the whole community has done; of course we can and will improve,
but I should not emphasize weak points: I think we have less than most
projects.
Cheers.

On 09/06/19 13:00, Andreas Neumann wrote:

> Hi,
>
> Steven Feldman conducted a survey on product management processes in
> OSGeo projects. The results will be presented at the FOSS4G in Bukarest.
>
> In agreement with Paolo, I participated on behalf of QGIS.ORG
> <http://QGIS.ORG> to submit and explain the current situation of
> QGIS.ORG <http://QGIS.ORG> in this aspect.
>
> I am forwarding the questionnaire and my replies for your review. If you
> find something wrong in my statements or if I missed something
> substantial, please speak up and I will send Steven a corrected version.
>
> Thanks and greetings,
> Andreas 
>
> ---------- Forwarded message ---------
> From: *Google Forms* <[hidden email]
> <mailto:[hidden email]>>
> Date: Sun, 9 Jun 2019 at 12:54
> Subject: Product management processes in OSGeo projects
> To: <[hidden email] <mailto:[hidden email]>>
>
>
> Google Forms
>
> Thanks for filling out Product management processes in OSGeo projects
> <https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
> Here's what we got from you:
>
>
>   Product management processes in OSGeo projects
>
> Thank you for agreeing to help me in researching product management
> processes in OSGeo projects. My aim is to try and establish:
>
> • Does the Open Source collaborative development model incorporate and
> support product management disciplines?
> • Are there formal product management strategies within the OSGeo Community?
> • How is a roadmap developed?
> • Is the roadmap inspired by a cohesive vision or is it driven by the
> willingness of larger users to fund features?
> • How do projects get to hear the voice of the user?
> • Do software development methodologies impact product management?
> • Are there best practices that we can learn from and share?
>
> Following on from this survey I plan to contact some (most) of the
> respondents and if you are available conduct a short interview with you
> via a call or by email.
>
> It would be great if you could complete this survey by 3rd June 2019.
>
> I hope to present the results of this research at FOSS4G at the end of
> the summer, I will also write up the results and share with our
> community and others. Subject to timing I will make an early version of
> my presentation/write up available to respondents for comment before
> publication.
>
> Thanks once again for your help
>
> May the FOSS be with you
>
> Steven
>
>
> Email address *
> [hidden email] <mailto:[hidden email]>
>
>
>     A bit about you and your project
>
> If you think someone else on your project steering team should be
> completing this survey as well as or instead of you please forward the
> survey to them
>
> Your name *
> Andreas Neumann
>
> Project *
> QGIS
>
> What is your role in the project team?
> Steering Committee Chair or Member, Contributor, Other?
> PSC and board member
>
> How long have you been active within the project team?
> 13 years, but only 4 years on PSC/board
>
> Are you willing to participate in a short interview
>
>   * Yes
>   * No
>   * Maybe
>
>
> Best way to contact you for an interview
>
>   * Google Hangouts
>   * Skype
>   * WhatsApp call
>   * email
>   * Other:
>
>
>     Product management processes
>
> I have set out a series of questions below that will help me to
> understand how your project sets goals, converts them to a roadmap and
> then prioritises features. It will make collating your response easier
> if you can respond to these questions but if you find that too tedious
> or if your responses don't fit with the structure of my questions then I
> have given you the option of including a long form text answer at the
> end of the questionnaire.
>
>
>     Vision and Goals
>
> Has your project set out a vision and a set of goals that drive the roadmap?
>
> Does your project have a clear statement of vision or purpose?
> Why are you and others committing time to this project? What do you hope
> to achieve?
>
>   * Yes
>   * No
>   * Sort of
>
>
> Does your project have a set of goals or targets that you are trying to
> achieve?
> These may be the metrics by which you can measure success,
>
>   * Yes
>   * No
>   * Sort of
>
>
> Do you gather any usage metrics about your project
>
>   * Yes
>   * No
>   * Other:
>
>
> Vision and goals
> If available please paste your vision and goals in this section or add a
> link to them
> No official vision yet - but that reminds me that we should come up with
> one and publish it. Here is one proposal (just formulated by myself and
> not discussed yet with the PSC. ): To make GIS available and affordable
> to anyone who is interested in using GIS, regardless of the budget and
> resources they have at hand. To be a user friendly GIS for Desktop,
> Server and Mobile. To be available for many platforms (Linux, Mac,
> Windows, Android). Road Map and new features to be defined by active
> users, funders and devlopers (bottom up and not top down). Note that
> this not the official vision - just my proposal from myself and not yet
> discussed and sanctioned by the PSC and voting members. I will start a
> discussion to come up with a vision and goals.
>
>
>     Roadmap
>
> How do you establish and maintain the roadmap for your project?
>
> Do you have a roadmap for your project?
>
>   * None
>   * 1 year
>   * 2 year
>   * 3 year
>   * Other:
>
>
> What methodology do you use to manage your roadmap?
> These are some of the most common methods for managing a roadmap, do you
> use one of them? If not please describe how you plan and communicate
> your roadmap.
>
>   * Priority Buckets (Now, Next, Later)
>   * Categorize, Cluster and Communicate (e.g.
>     https://library.gv.com/climbing-mount-enterprise-99a4d014f942
>     <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
>     )
>   * 3 feature buckets (Customer requests, Metrics movers, Customer delight)
>   * No formal process to manage roadmap
>   * Other:
>
>
> Link to your roadmap
> If you publish a roadmap please provide a link to the current version
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html
>
>
>     Feature prioritisation
>
> How do you prioritise features within the next release(s) of your project?
>
> Sponsored Features
> To what extent do you prioritise features that are wholly or partly
> sponsored by users of the software? Does this create any conflicts in
> terms of feature prioritisation or your roadmap? Please be assured that
> any responses on sponsored features will be anonymised so that your
> project and sponsors will not be identified.
> There is no differentiation between features that are sponsored and
> features that are developed and submitted from volunteers. Because our
> road map is strictly time-based and not feature based (we don't
> communicate or promise any new features in advance) there is also no
> top-down prioritization done by the PSC. It is really the developers who
> decide when something is ready to be released and it is also the
> developers who prioritize their work by themselves. If a customer of a
> QGIS developer comes up with a new feature and new requirements, they
> can consult the road map with the time line and discuss with their
> developer to find out what release date can be realistically targeted,
> taking into account time for preparation, discussion of QEP (QGIS
> enhancement proposal), development time, testing and bug fixing.
>
> What methodology do you use to prioritise features within your next
> release?
> These are some of the most common methods for prioritising features, do
> you use one of them? If not please describe how you prioritise features.
>
>   * Kano (Delighters, Satisfiers, Basic Expectations)
>   * MoSCoW (Must, Should, Could, Won't)
>   * Buy a Feature (each team member gets an allocation of points and
>     assign to features)
>   * RICE (Reach, Impact, Confidence, Effort)
>   * No formal process to prioritise features
>   * Other:
>
>
>     Requirements Capture
>
> How do you capture and document requirements within your project?
>
> Requirements
> How do you identify user requirements
>
>   * User Stories
>   * Job Stories
>   * Detailed feature descriptions
>   * Surveys
>   * Other:
>
>
>     I can't describe our product management process by responding to
>     your questions!
>
> This is the pint where you can just write whatever you wish about the
> product management processes in your project and include answers to the
> questions that I have neglected to ask!
>
> Answering your way
> Write whatever you wish in this section
> It was a very good decision to introduce a strictly time-based road map
> for QGIS and don't wait for specific features to be ready until we
> release the upcoming version. Before that switch to a time-based release
> schedule we had endless discussions when a new release would be ready or
> not. The only exception is when we do a new major release that is
> dependent on major technological changes, such as the change from QGIS 1
> to 2, or 2 to 3, where a lot of technical changes happened under the
> hood (e.g. switching qt version or Python version, API changes, etc.).
> In such a major change everything has to work as expected and it is very
> hard to predict when everything is ready. The other convention we have
> is, that during a major release cycle, the API has to remain stable. API
> changes are only allowed when a new major QGIS version is prepared. We
> often work as a "do-ocracy". Many tasks and development work are picked
> up by contributors or developers as they see the need and can contribute
> resources. Coordination happens on regular PSC meetings (monthly),
> bi-annual developer meetings and through Github and mailing lists or on
> IRC. The "bottom up" process regarding new features and their
> prioritization usually works fine for us currently - it gives the
> users/funders/developers a lot of freedom to decide when something can
> get into a future QGIS version. They are not at the mercy of a product
> management team or of the PSC who would decide on what gets into QGIS or
> not. So the power is at the users/funders and developers and not with
> the PSC and board. Should something really controversial come up during
> the process, we have an established voting system consisting of
> community voting members, user groups voting members and an OSGEO
> representative. We don't / can't work like a classical software company,
> because QGIS developers are not the employees of QGIS.ORG
> <http://QGIS.ORG>, but are individual developers, volunteers or
> employees from support and development companies who work independent of
> QGIS.ORG <http://QGIS.ORG>, but collaborate under the umbrella of
> QGIS.ORG <http://QGIS.ORG>. In this setup of our organization we can't
> dictate or enforce rules and decisions on our contributors and
> developers but have to work out compromises and convince the
> contributors to accept the proposals by the community, PSC and board.
> TODO: QGIS as a project certainly has some weak points we should improve
> in our organization and release process and project management. We
> should come up with a common and clear vision. Quality assurance is
> always a challenge and most of our donations and sustaining membership
> contributions go into bug fixing and improving our code quality and testing.
>
>
>     The last bit
>
> A few questions about the organisation of product management within your
> project, your analysis of your competitors and your communications with
> your users.
>
> How do product management decisions sit within your project's organisation?
> Who makes the decisions?
>
>   * Project Steering Committee
>   * A Product Management sub-committee
>   * The contributors decide
>   * Other:
>
>
> Do you track what your competitors are doing?
>
>   * Yes
>   * No
>   * We don't have any competitors
>   * Other:
>
>
> How do you track competitor developments?
> If you are tracking competitor developments how do you do so? If not,
> can you explain why this is not a consideration in determining the
> direction of your project?
> If our contributors and funders think that some competitor
> project/product offers something we don't have, or does something than
> we do, they can bring ideas to the table and if it is important to them,
> they will invest (time and/or financial resources) to add these missing
> pieces or improve our software and project.
>
> Do end users get a say on the roadmap?
> Do you have a channel for dialogue with your users? How do you reach
> them and how important is their input in determining your roadmap?
> Yes, definitely. We have votes on QGIS grant proposals and with their
> investments (time and money) they can decide what gets into QGIS or not.
>
> Any last thoughts?
> Anything I haven't asked you that you would like to share
>
> Create your own Google Form
> <https://docs.google.com/forms?usp=mail_form_link>
>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG <http://QGIS.ORG> board member (treasurer)
>
> _______________________________________________
> 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: Fwd: Product management processes in OSGeo projects

Tim Sutton-6
Good replies Andreas!

I like your vision.

I think it would be useful to also have a vision for QGIS.org. My vision has always been to have a well funded sustainable organisation with dedicated staff that work at the direction of the board to maintain the project infrastructure and key resources (documentation, testing environment etc.) whilst leaving the community to innovate and bring new features and functionality to the project.

I also think that part of our vision should be to have a seat at the table of major industry standards bodies so that we can help to set the direction of the industry as a whole. Maybe this last one is achieved by OSGEO but I think we should have more presence there as probably the world's most used desktop GIS.

Thanks for responding to the survey Andreas!

Tim Sutton 
Co-founder of Kartoza 
Ex-QGIS project chairman 

On 9 Jun 2019, at 19:45, Paolo Cavallini <[hidden email]> wrote:

Hi Andreas,
thanks for dealing with this.
I'm happy with your replies. Just a few comments:
* I think we do collect some usage metrics (volume of downloads on
cloudflare, hits on versions.txt, number of plugin downloads, etc.),
although I agree that none of them is sensu stricto a measure, rather an
estimate
* I can't read your replies on Roadmap, Requirements capture (Other) in
its entirety
* I think it is fair to say that we do manage our roadmap by open and
public discussion on our mailing list and PSC meetings
* I find your TODO a bit pessimistic, I believe we have to be very proud
of what the whole community has done; of course we can and will improve,
but I should not emphasize weak points: I think we have less than most
projects.
Cheers.

On 09/06/19 13:00, Andreas Neumann wrote:
Hi,

Steven Feldman conducted a survey on product management processes in
OSGeo projects. The results will be presented at the FOSS4G in Bukarest.

In agreement with Paolo, I participated on behalf of QGIS.ORG
<http://QGIS.ORG> to submit and explain the current situation of
QGIS.ORG <http://QGIS.ORG> in this aspect.

I am forwarding the questionnaire and my replies for your review. If you
find something wrong in my statements or if I missed something
substantial, please speak up and I will send Steven a corrected version.

Thanks and greetings,
Andreas 

---------- Forwarded message ---------
From: *Google Forms* <[hidden email]
<[hidden email]>>
Date: Sun, 9 Jun 2019 at 12:54
Subject: Product management processes in OSGeo projects
To: <[hidden email] <[hidden email]>>


Google Forms

Thanks for filling out Product management processes in OSGeo projects
<https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
Here's what we got from you:


 Product management processes in OSGeo projects

Thank you for agreeing to help me in researching product management
processes in OSGeo projects. My aim is to try and establish:

• Does the Open Source collaborative development model incorporate and
support product management disciplines?
• Are there formal product management strategies within the OSGeo Community?
• How is a roadmap developed?
• Is the roadmap inspired by a cohesive vision or is it driven by the
willingness of larger users to fund features?
• How do projects get to hear the voice of the user?
• Do software development methodologies impact product management?
• Are there best practices that we can learn from and share?

Following on from this survey I plan to contact some (most) of the
respondents and if you are available conduct a short interview with you
via a call or by email.

It would be great if you could complete this survey by 3rd June 2019.

I hope to present the results of this research at FOSS4G at the end of
the summer, I will also write up the results and share with our
community and others. Subject to timing I will make an early version of
my presentation/write up available to respondents for comment before
publication.

Thanks once again for your help

May the FOSS be with you

Steven


Email address *
[hidden email] <[hidden email]>


   A bit about you and your project

If you think someone else on your project steering team should be
completing this survey as well as or instead of you please forward the
survey to them

Your name *
Andreas Neumann

Project *
QGIS

What is your role in the project team?
Steering Committee Chair or Member, Contributor, Other?
PSC and board member

How long have you been active within the project team?
13 years, but only 4 years on PSC/board

Are you willing to participate in a short interview

 * Yes
 * No
 * Maybe


Best way to contact you for an interview

 * Google Hangouts
 * Skype
 * WhatsApp call
 * email
 * Other:


   Product management processes

I have set out a series of questions below that will help me to
understand how your project sets goals, converts them to a roadmap and
then prioritises features. It will make collating your response easier
if you can respond to these questions but if you find that too tedious
or if your responses don't fit with the structure of my questions then I
have given you the option of including a long form text answer at the
end of the questionnaire.


   Vision and Goals

Has your project set out a vision and a set of goals that drive the roadmap?

Does your project have a clear statement of vision or purpose?
Why are you and others committing time to this project? What do you hope
to achieve?

 * Yes
 * No
 * Sort of


Does your project have a set of goals or targets that you are trying to
achieve?
These may be the metrics by which you can measure success,

 * Yes
 * No
 * Sort of


Do you gather any usage metrics about your project

 * Yes
 * No
 * Other:


Vision and goals
If available please paste your vision and goals in this section or add a
link to them
No official vision yet - but that reminds me that we should come up with
one and publish it. Here is one proposal (just formulated by myself and
not discussed yet with the PSC. ): To make GIS available and affordable
to anyone who is interested in using GIS, regardless of the budget and
resources they have at hand. To be a user friendly GIS for Desktop,
Server and Mobile. To be available for many platforms (Linux, Mac,
Windows, Android). Road Map and new features to be defined by active
users, funders and devlopers (bottom up and not top down). Note that
this not the official vision - just my proposal from myself and not yet
discussed and sanctioned by the PSC and voting members. I will start a
discussion to come up with a vision and goals.


   Roadmap

How do you establish and maintain the roadmap for your project?

Do you have a roadmap for your project?

 * None
 * 1 year
 * 2 year
 * 3 year
 * Other:


What methodology do you use to manage your roadmap?
These are some of the most common methods for managing a roadmap, do you
use one of them? If not please describe how you plan and communicate
your roadmap.

 * Priority Buckets (Now, Next, Later)
 * Categorize, Cluster and Communicate (e.g.
   https://library.gv.com/climbing-mount-enterprise-99a4d014f942
   <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
   )
 * 3 feature buckets (Customer requests, Metrics movers, Customer delight)
 * No formal process to manage roadmap
 * Other:


Link to your roadmap
If you publish a roadmap please provide a link to the current version
https://www.qgis.org/en/site/getinvolved/development/roadmap.html


   Feature prioritisation

How do you prioritise features within the next release(s) of your project?

Sponsored Features
To what extent do you prioritise features that are wholly or partly
sponsored by users of the software? Does this create any conflicts in
terms of feature prioritisation or your roadmap? Please be assured that
any responses on sponsored features will be anonymised so that your
project and sponsors will not be identified.
There is no differentiation between features that are sponsored and
features that are developed and submitted from volunteers. Because our
road map is strictly time-based and not feature based (we don't
communicate or promise any new features in advance) there is also no
top-down prioritization done by the PSC. It is really the developers who
decide when something is ready to be released and it is also the
developers who prioritize their work by themselves. If a customer of a
QGIS developer comes up with a new feature and new requirements, they
can consult the road map with the time line and discuss with their
developer to find out what release date can be realistically targeted,
taking into account time for preparation, discussion of QEP (QGIS
enhancement proposal), development time, testing and bug fixing.

What methodology do you use to prioritise features within your next
release?
These are some of the most common methods for prioritising features, do
you use one of them? If not please describe how you prioritise features.

 * Kano (Delighters, Satisfiers, Basic Expectations)
 * MoSCoW (Must, Should, Could, Won't)
 * Buy a Feature (each team member gets an allocation of points and
   assign to features)
 * RICE (Reach, Impact, Confidence, Effort)
 * No formal process to prioritise features
 * Other:


   Requirements Capture

How do you capture and document requirements within your project?

Requirements
How do you identify user requirements

 * User Stories
 * Job Stories
 * Detailed feature descriptions
 * Surveys
 * Other:


   I can't describe our product management process by responding to
   your questions!

This is the pint where you can just write whatever you wish about the
product management processes in your project and include answers to the
questions that I have neglected to ask!

Answering your way
Write whatever you wish in this section
It was a very good decision to introduce a strictly time-based road map
for QGIS and don't wait for specific features to be ready until we
release the upcoming version. Before that switch to a time-based release
schedule we had endless discussions when a new release would be ready or
not. The only exception is when we do a new major release that is
dependent on major technological changes, such as the change from QGIS 1
to 2, or 2 to 3, where a lot of technical changes happened under the
hood (e.g. switching qt version or Python version, API changes, etc.).
In such a major change everything has to work as expected and it is very
hard to predict when everything is ready. The other convention we have
is, that during a major release cycle, the API has to remain stable. API
changes are only allowed when a new major QGIS version is prepared. We
often work as a "do-ocracy". Many tasks and development work are picked
up by contributors or developers as they see the need and can contribute
resources. Coordination happens on regular PSC meetings (monthly),
bi-annual developer meetings and through Github and mailing lists or on
IRC. The "bottom up" process regarding new features and their
prioritization usually works fine for us currently - it gives the
users/funders/developers a lot of freedom to decide when something can
get into a future QGIS version. They are not at the mercy of a product
management team or of the PSC who would decide on what gets into QGIS or
not. So the power is at the users/funders and developers and not with
the PSC and board. Should something really controversial come up during
the process, we have an established voting system consisting of
community voting members, user groups voting members and an OSGEO
representative. We don't / can't work like a classical software company,
because QGIS developers are not the employees of QGIS.ORG
<http://QGIS.ORG>, but are individual developers, volunteers or
employees from support and development companies who work independent of
QGIS.ORG <http://QGIS.ORG>, but collaborate under the umbrella of
QGIS.ORG <http://QGIS.ORG>. In this setup of our organization we can't
dictate or enforce rules and decisions on our contributors and
developers but have to work out compromises and convince the
contributors to accept the proposals by the community, PSC and board.
TODO: QGIS as a project certainly has some weak points we should improve
in our organization and release process and project management. We
should come up with a common and clear vision. Quality assurance is
always a challenge and most of our donations and sustaining membership
contributions go into bug fixing and improving our code quality and testing.


   The last bit

A few questions about the organisation of product management within your
project, your analysis of your competitors and your communications with
your users.

How do product management decisions sit within your project's organisation?
Who makes the decisions?

 * Project Steering Committee
 * A Product Management sub-committee
 * The contributors decide
 * Other:


Do you track what your competitors are doing?

 * Yes
 * No
 * We don't have any competitors
 * Other:


How do you track competitor developments?
If you are tracking competitor developments how do you do so? If not,
can you explain why this is not a consideration in determining the
direction of your project?
If our contributors and funders think that some competitor
project/product offers something we don't have, or does something than
we do, they can bring ideas to the table and if it is important to them,
they will invest (time and/or financial resources) to add these missing
pieces or improve our software and project.

Do end users get a say on the roadmap?
Do you have a channel for dialogue with your users? How do you reach
them and how important is their input in determining your roadmap?
Yes, definitely. We have votes on QGIS grant proposals and with their
investments (time and money) they can decide what gets into QGIS or not.

Any last thoughts?
Anything I haven't asked you that you would like to share

Create your own Google Form
<https://docs.google.com/forms?usp=mail_form_link>



--

--
Andreas Neumann
QGIS.ORG <http://QGIS.ORG> board member (treasurer)

_______________________________________________
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: Fwd: Product management processes in OSGeo projects

Régis Haubourg -2

Hi all,

Good answers Andreas. You summarize very well the project.

I also second Tim's vision. Our vision, beyond what you wrote, is to reach a sustainable organization able to tackle quality assessment, doc, and get involved in GIS work-groups upstream (OGC, UN, national workgroups via QGIS user groupes / OSGEO local Chapter).

Sustainable is a key here. We need to onboard new contributors. We need to be more accessible (always). We need to adress students and schools. We need happy dev's not having to do to much benevolent work (I mean night & days & weekend is not sustainable). 

Let's keep going this way !

Régis

Le 11/06/2019 à 08:35, Tim Sutton a écrit :
Good replies Andreas!

I like your vision.

I think it would be useful to also have a vision for QGIS.org. My vision has always been to have a well funded sustainable organisation with dedicated staff that work at the direction of the board to maintain the project infrastructure and key resources (documentation, testing environment etc.) whilst leaving the community to innovate and bring new features and functionality to the project.

I also think that part of our vision should be to have a seat at the table of major industry standards bodies so that we can help to set the direction of the industry as a whole. Maybe this last one is achieved by OSGEO but I think we should have more presence there as probably the world's most used desktop GIS.

Thanks for responding to the survey Andreas!

Tim Sutton 
Co-founder of Kartoza 
Ex-QGIS project chairman 

On 9 Jun 2019, at 19:45, Paolo Cavallini <[hidden email]> wrote:

Hi Andreas,
thanks for dealing with this.
I'm happy with your replies. Just a few comments:
* I think we do collect some usage metrics (volume of downloads on
cloudflare, hits on versions.txt, number of plugin downloads, etc.),
although I agree that none of them is sensu stricto a measure, rather an
estimate
* I can't read your replies on Roadmap, Requirements capture (Other) in
its entirety
* I think it is fair to say that we do manage our roadmap by open and
public discussion on our mailing list and PSC meetings
* I find your TODO a bit pessimistic, I believe we have to be very proud
of what the whole community has done; of course we can and will improve,
but I should not emphasize weak points: I think we have less than most
projects.
Cheers.

On 09/06/19 13:00, Andreas Neumann wrote:
Hi,

Steven Feldman conducted a survey on product management processes in
OSGeo projects. The results will be presented at the FOSS4G in Bukarest.

In agreement with Paolo, I participated on behalf of QGIS.ORG
<http://QGIS.ORG> to submit and explain the current situation of
QGIS.ORG <http://QGIS.ORG> in this aspect.

I am forwarding the questionnaire and my replies for your review. If you
find something wrong in my statements or if I missed something
substantial, please speak up and I will send Steven a corrected version.

Thanks and greetings,
Andreas 

---------- Forwarded message ---------
From: *Google Forms* <[hidden email]
<[hidden email]>>
Date: Sun, 9 Jun 2019 at 12:54
Subject: Product management processes in OSGeo projects
To: <[hidden email] <[hidden email]>>


Google Forms

Thanks for filling out Product management processes in OSGeo projects
<https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
Here's what we got from you:


 Product management processes in OSGeo projects

Thank you for agreeing to help me in researching product management
processes in OSGeo projects. My aim is to try and establish:

• Does the Open Source collaborative development model incorporate and
support product management disciplines?
• Are there formal product management strategies within the OSGeo Community?
• How is a roadmap developed?
• Is the roadmap inspired by a cohesive vision or is it driven by the
willingness of larger users to fund features?
• How do projects get to hear the voice of the user?
• Do software development methodologies impact product management?
• Are there best practices that we can learn from and share?

Following on from this survey I plan to contact some (most) of the
respondents and if you are available conduct a short interview with you
via a call or by email.

It would be great if you could complete this survey by 3rd June 2019.

I hope to present the results of this research at FOSS4G at the end of
the summer, I will also write up the results and share with our
community and others. Subject to timing I will make an early version of
my presentation/write up available to respondents for comment before
publication.

Thanks once again for your help

May the FOSS be with you

Steven


Email address *
[hidden email] <[hidden email]>


   A bit about you and your project

If you think someone else on your project steering team should be
completing this survey as well as or instead of you please forward the
survey to them

Your name *
Andreas Neumann

Project *
QGIS

What is your role in the project team?
Steering Committee Chair or Member, Contributor, Other?
PSC and board member

How long have you been active within the project team?
13 years, but only 4 years on PSC/board

Are you willing to participate in a short interview

 * Yes
 * No
 * Maybe


Best way to contact you for an interview

 * Google Hangouts
 * Skype
 * WhatsApp call
 * email
 * Other:


   Product management processes

I have set out a series of questions below that will help me to
understand how your project sets goals, converts them to a roadmap and
then prioritises features. It will make collating your response easier
if you can respond to these questions but if you find that too tedious
or if your responses don't fit with the structure of my questions then I
have given you the option of including a long form text answer at the
end of the questionnaire.


   Vision and Goals

Has your project set out a vision and a set of goals that drive the roadmap?

Does your project have a clear statement of vision or purpose?
Why are you and others committing time to this project? What do you hope
to achieve?

 * Yes
 * No
 * Sort of


Does your project have a set of goals or targets that you are trying to
achieve?
These may be the metrics by which you can measure success,

 * Yes
 * No
 * Sort of


Do you gather any usage metrics about your project

 * Yes
 * No
 * Other:


Vision and goals
If available please paste your vision and goals in this section or add a
link to them
No official vision yet - but that reminds me that we should come up with
one and publish it. Here is one proposal (just formulated by myself and
not discussed yet with the PSC. ): To make GIS available and affordable
to anyone who is interested in using GIS, regardless of the budget and
resources they have at hand. To be a user friendly GIS for Desktop,
Server and Mobile. To be available for many platforms (Linux, Mac,
Windows, Android). Road Map and new features to be defined by active
users, funders and devlopers (bottom up and not top down). Note that
this not the official vision - just my proposal from myself and not yet
discussed and sanctioned by the PSC and voting members. I will start a
discussion to come up with a vision and goals.


   Roadmap

How do you establish and maintain the roadmap for your project?

Do you have a roadmap for your project?

 * None
 * 1 year
 * 2 year
 * 3 year
 * Other:


What methodology do you use to manage your roadmap?
These are some of the most common methods for managing a roadmap, do you
use one of them? If not please describe how you plan and communicate
your roadmap.

 * Priority Buckets (Now, Next, Later)
 * Categorize, Cluster and Communicate (e.g.
   https://library.gv.com/climbing-mount-enterprise-99a4d014f942
   <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
   )
 * 3 feature buckets (Customer requests, Metrics movers, Customer delight)
 * No formal process to manage roadmap
 * Other:


Link to your roadmap
If you publish a roadmap please provide a link to the current version
https://www.qgis.org/en/site/getinvolved/development/roadmap.html


   Feature prioritisation

How do you prioritise features within the next release(s) of your project?

Sponsored Features
To what extent do you prioritise features that are wholly or partly
sponsored by users of the software? Does this create any conflicts in
terms of feature prioritisation or your roadmap? Please be assured that
any responses on sponsored features will be anonymised so that your
project and sponsors will not be identified.
There is no differentiation between features that are sponsored and
features that are developed and submitted from volunteers. Because our
road map is strictly time-based and not feature based (we don't
communicate or promise any new features in advance) there is also no
top-down prioritization done by the PSC. It is really the developers who
decide when something is ready to be released and it is also the
developers who prioritize their work by themselves. If a customer of a
QGIS developer comes up with a new feature and new requirements, they
can consult the road map with the time line and discuss with their
developer to find out what release date can be realistically targeted,
taking into account time for preparation, discussion of QEP (QGIS
enhancement proposal), development time, testing and bug fixing.

What methodology do you use to prioritise features within your next
release?
These are some of the most common methods for prioritising features, do
you use one of them? If not please describe how you prioritise features.

 * Kano (Delighters, Satisfiers, Basic Expectations)
 * MoSCoW (Must, Should, Could, Won't)
 * Buy a Feature (each team member gets an allocation of points and
   assign to features)
 * RICE (Reach, Impact, Confidence, Effort)
 * No formal process to prioritise features
 * Other:


   Requirements Capture

How do you capture and document requirements within your project?

Requirements
How do you identify user requirements

 * User Stories
 * Job Stories
 * Detailed feature descriptions
 * Surveys
 * Other:


   I can't describe our product management process by responding to
   your questions!

This is the pint where you can just write whatever you wish about the
product management processes in your project and include answers to the
questions that I have neglected to ask!

Answering your way
Write whatever you wish in this section
It was a very good decision to introduce a strictly time-based road map
for QGIS and don't wait for specific features to be ready until we
release the upcoming version. Before that switch to a time-based release
schedule we had endless discussions when a new release would be ready or
not. The only exception is when we do a new major release that is
dependent on major technological changes, such as the change from QGIS 1
to 2, or 2 to 3, where a lot of technical changes happened under the
hood (e.g. switching qt version or Python version, API changes, etc.).
In such a major change everything has to work as expected and it is very
hard to predict when everything is ready. The other convention we have
is, that during a major release cycle, the API has to remain stable. API
changes are only allowed when a new major QGIS version is prepared. We
often work as a "do-ocracy". Many tasks and development work are picked
up by contributors or developers as they see the need and can contribute
resources. Coordination happens on regular PSC meetings (monthly),
bi-annual developer meetings and through Github and mailing lists or on
IRC. The "bottom up" process regarding new features and their
prioritization usually works fine for us currently - it gives the
users/funders/developers a lot of freedom to decide when something can
get into a future QGIS version. They are not at the mercy of a product
management team or of the PSC who would decide on what gets into QGIS or
not. So the power is at the users/funders and developers and not with
the PSC and board. Should something really controversial come up during
the process, we have an established voting system consisting of
community voting members, user groups voting members and an OSGEO
representative. We don't / can't work like a classical software company,
because QGIS developers are not the employees of QGIS.ORG
<http://QGIS.ORG>, but are individual developers, volunteers or
employees from support and development companies who work independent of
QGIS.ORG <http://QGIS.ORG>, but collaborate under the umbrella of
QGIS.ORG <http://QGIS.ORG>. In this setup of our organization we can't
dictate or enforce rules and decisions on our contributors and
developers but have to work out compromises and convince the
contributors to accept the proposals by the community, PSC and board.
TODO: QGIS as a project certainly has some weak points we should improve
in our organization and release process and project management. We
should come up with a common and clear vision. Quality assurance is
always a challenge and most of our donations and sustaining membership
contributions go into bug fixing and improving our code quality and testing.


   The last bit

A few questions about the organisation of product management within your
project, your analysis of your competitors and your communications with
your users.

How do product management decisions sit within your project's organisation?
Who makes the decisions?

 * Project Steering Committee
 * A Product Management sub-committee
 * The contributors decide
 * Other:


Do you track what your competitors are doing?

 * Yes
 * No
 * We don't have any competitors
 * Other:


How do you track competitor developments?
If you are tracking competitor developments how do you do so? If not,
can you explain why this is not a consideration in determining the
direction of your project?
If our contributors and funders think that some competitor
project/product offers something we don't have, or does something than
we do, they can bring ideas to the table and if it is important to them,
they will invest (time and/or financial resources) to add these missing
pieces or improve our software and project.

Do end users get a say on the roadmap?
Do you have a channel for dialogue with your users? How do you reach
them and how important is their input in determining your roadmap?
Yes, definitely. We have votes on QGIS grant proposals and with their
investments (time and money) they can decide what gets into QGIS or not.

Any last thoughts?
Anything I haven't asked you that you would like to share

Create your own Google Form
<https://docs.google.com/forms?usp=mail_form_link>



--

--
Andreas Neumann
QGIS.ORG <http://QGIS.ORG> board member (treasurer)

_______________________________________________
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
-- 
Open Source GIS Expert / Water management 

mail: [hidden email] 
tél: 0033 184 257 870
---------------------------------
http://oslandia.com/

OSLANDIA IS AN INNOVATIVE COMPANY SPECIALIZED IN GIS ARCHITECTURE. WE
PROVIDE SERVICE ON OPEN SOURCE SOFTWARE FOR WHICH WE ARE EDITORS OR
RECOGNIZED EXPERTS.

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

Re: Fwd: Product management processes in OSGeo projects

pcav
Hi all,
Tim proposal implies a budget in the order of a few million
dollars/euros. Does anybody have ideas about large donors to approach?
Cheers.

On 11/06/19 09:41, Régis Haubourg wrote:

> Hi all,
>
> Good answers Andreas. You summarize very well the project.
>
> I also second Tim's vision. Our vision, beyond what you wrote, is to
> reach a sustainable organization able to tackle quality assessment, doc,
> and get involved in GIS work-groups upstream (OGC, UN, national
> workgroups via QGIS user groupes / OSGEO local Chapter).
>
> Sustainable is a key here. We need to onboard new contributors. We need
> to be more accessible (always). We need to adress students and schools.
> We need happy dev's not having to do to much benevolent work (I mean
> night & days & weekend is not sustainable). 
>
> Let's keep going this way !
>
> Régis
>
> Le 11/06/2019 à 08:35, Tim Sutton a écrit :
>> Good replies Andreas!
>>
>> I like your vision.
>>
>> I think it would be useful to also have a vision for QGIS.org
>> <http://QGIS.org>. My vision has always been to have a well funded
>> sustainable organisation with dedicated staff that work at the
>> direction of the board to maintain the project infrastructure and key
>> resources (documentation, testing environment etc.) whilst leaving the
>> community to innovate and bring new features and functionality to the
>> project.
>>
>> I also think that part of our vision should be to have a seat at the
>> table of major industry standards bodies so that we can help to set
>> the direction of the industry as a whole. Maybe this last one is
>> achieved by OSGEO but I think we should have more presence there as
>> probably the world's most used desktop GIS.
>>
>> Thanks for responding to the survey Andreas!
>>
>> Tim Sutton 
>> Co-founder of Kartoza 
>> Ex-QGIS project chairman 
>>
>> On 9 Jun 2019, at 19:45, Paolo Cavallini <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>> Hi Andreas,
>>> thanks for dealing with this.
>>> I'm happy with your replies. Just a few comments:
>>> * I think we do collect some usage metrics (volume of downloads on
>>> cloudflare, hits on versions.txt, number of plugin downloads, etc.),
>>> although I agree that none of them is sensu stricto a measure, rather an
>>> estimate
>>> * I can't read your replies on Roadmap, Requirements capture (Other) in
>>> its entirety
>>> * I think it is fair to say that we do manage our roadmap by open and
>>> public discussion on our mailing list and PSC meetings
>>> * I find your TODO a bit pessimistic, I believe we have to be very proud
>>> of what the whole community has done; of course we can and will improve,
>>> but I should not emphasize weak points: I think we have less than most
>>> projects.
>>> Cheers.
>>>
>>> On 09/06/19 13:00, Andreas Neumann wrote:
>>>> Hi,
>>>>
>>>> Steven Feldman conducted a survey on product management processes in
>>>> OSGeo projects. The results will be presented at the FOSS4G in Bukarest.
>>>>
>>>> In agreement with Paolo, I participated on behalf of QGIS.ORG
>>>> <http://QGIS.ORG>
>>>> <http://QGIS.ORG> to submit and explain the current situation of
>>>> QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG> in this aspect.
>>>>
>>>> I am forwarding the questionnaire and my replies for your review. If you
>>>> find something wrong in my statements or if I missed something
>>>> substantial, please speak up and I will send Steven a corrected version.
>>>>
>>>> Thanks and greetings,
>>>> Andreas 
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: *Google Forms* <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>>
>>>> Date: Sun, 9 Jun 2019 at 12:54
>>>> Subject: Product management processes in OSGeo projects
>>>> To: <[hidden email] <mailto:[hidden email]>
>>>> <mailto:[hidden email]>>
>>>>
>>>>
>>>> Google Forms
>>>>
>>>> Thanks for filling out Product management processes in OSGeo projects
>>>> <https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
>>>> Here's what we got from you:
>>>>
>>>>
>>>>  Product management processes in OSGeo projects
>>>>
>>>> Thank you for agreeing to help me in researching product management
>>>> processes in OSGeo projects. My aim is to try and establish:
>>>>
>>>> • Does the Open Source collaborative development model incorporate and
>>>> support product management disciplines?
>>>> • Are there formal product management strategies within the OSGeo
>>>> Community?
>>>> • How is a roadmap developed?
>>>> • Is the roadmap inspired by a cohesive vision or is it driven by the
>>>> willingness of larger users to fund features?
>>>> • How do projects get to hear the voice of the user?
>>>> • Do software development methodologies impact product management?
>>>> • Are there best practices that we can learn from and share?
>>>>
>>>> Following on from this survey I plan to contact some (most) of the
>>>> respondents and if you are available conduct a short interview with you
>>>> via a call or by email.
>>>>
>>>> It would be great if you could complete this survey by 3rd June 2019.
>>>>
>>>> I hope to present the results of this research at FOSS4G at the end of
>>>> the summer, I will also write up the results and share with our
>>>> community and others. Subject to timing I will make an early version of
>>>> my presentation/write up available to respondents for comment before
>>>> publication.
>>>>
>>>> Thanks once again for your help
>>>>
>>>> May the FOSS be with you
>>>>
>>>> Steven
>>>>
>>>>
>>>> Email address *
>>>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email]>
>>>>
>>>>
>>>>    A bit about you and your project
>>>>
>>>> If you think someone else on your project steering team should be
>>>> completing this survey as well as or instead of you please forward the
>>>> survey to them
>>>>
>>>> Your name *
>>>> Andreas Neumann
>>>>
>>>> Project *
>>>> QGIS
>>>>
>>>> What is your role in the project team?
>>>> Steering Committee Chair or Member, Contributor, Other?
>>>> PSC and board member
>>>>
>>>> How long have you been active within the project team?
>>>> 13 years, but only 4 years on PSC/board
>>>>
>>>> Are you willing to participate in a short interview
>>>>
>>>>  * Yes
>>>>  * No
>>>>  * Maybe
>>>>
>>>>
>>>> Best way to contact you for an interview
>>>>
>>>>  * Google Hangouts
>>>>  * Skype
>>>>  * WhatsApp call
>>>>  * email
>>>>  * Other:
>>>>
>>>>
>>>>    Product management processes
>>>>
>>>> I have set out a series of questions below that will help me to
>>>> understand how your project sets goals, converts them to a roadmap and
>>>> then prioritises features. It will make collating your response easier
>>>> if you can respond to these questions but if you find that too tedious
>>>> or if your responses don't fit with the structure of my questions then I
>>>> have given you the option of including a long form text answer at the
>>>> end of the questionnaire.
>>>>
>>>>
>>>>    Vision and Goals
>>>>
>>>> Has your project set out a vision and a set of goals that drive the
>>>> roadmap?
>>>>
>>>> Does your project have a clear statement of vision or purpose?
>>>> Why are you and others committing time to this project? What do you hope
>>>> to achieve?
>>>>
>>>>  * Yes
>>>>  * No
>>>>  * Sort of
>>>>
>>>>
>>>> Does your project have a set of goals or targets that you are trying to
>>>> achieve?
>>>> These may be the metrics by which you can measure success,
>>>>
>>>>  * Yes
>>>>  * No
>>>>  * Sort of
>>>>
>>>>
>>>> Do you gather any usage metrics about your project
>>>>
>>>>  * Yes
>>>>  * No
>>>>  * Other:
>>>>
>>>>
>>>> Vision and goals
>>>> If available please paste your vision and goals in this section or add a
>>>> link to them
>>>> No official vision yet - but that reminds me that we should come up with
>>>> one and publish it. Here is one proposal (just formulated by myself and
>>>> not discussed yet with the PSC. ): To make GIS available and affordable
>>>> to anyone who is interested in using GIS, regardless of the budget and
>>>> resources they have at hand. To be a user friendly GIS for Desktop,
>>>> Server and Mobile. To be available for many platforms (Linux, Mac,
>>>> Windows, Android). Road Map and new features to be defined by active
>>>> users, funders and devlopers (bottom up and not top down). Note that
>>>> this not the official vision - just my proposal from myself and not yet
>>>> discussed and sanctioned by the PSC and voting members. I will start a
>>>> discussion to come up with a vision and goals.
>>>>
>>>>
>>>>    Roadmap
>>>>
>>>> How do you establish and maintain the roadmap for your project?
>>>>
>>>> Do you have a roadmap for your project?
>>>>
>>>>  * None
>>>>  * 1 year
>>>>  * 2 year
>>>>  * 3 year
>>>>  * Other:
>>>>
>>>>
>>>> What methodology do you use to manage your roadmap?
>>>> These are some of the most common methods for managing a roadmap, do you
>>>> use one of them? If not please describe how you plan and communicate
>>>> your roadmap.
>>>>
>>>>  * Priority Buckets (Now, Next, Later)
>>>>  * Categorize, Cluster and Communicate (e.g.
>>>>    https://library.gv.com/climbing-mount-enterprise-99a4d014f942
>>>>    <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
>>>>    )
>>>>  * 3 feature buckets (Customer requests, Metrics movers, Customer
>>>> delight)
>>>>  * No formal process to manage roadmap
>>>>  * Other:
>>>>
>>>>
>>>> Link to your roadmap
>>>> If you publish a roadmap please provide a link to the current version
>>>> https://www.qgis.org/en/site/getinvolved/development/roadmap.html
>>>>
>>>>
>>>>    Feature prioritisation
>>>>
>>>> How do you prioritise features within the next release(s) of your
>>>> project?
>>>>
>>>> Sponsored Features
>>>> To what extent do you prioritise features that are wholly or partly
>>>> sponsored by users of the software? Does this create any conflicts in
>>>> terms of feature prioritisation or your roadmap? Please be assured that
>>>> any responses on sponsored features will be anonymised so that your
>>>> project and sponsors will not be identified.
>>>> There is no differentiation between features that are sponsored and
>>>> features that are developed and submitted from volunteers. Because our
>>>> road map is strictly time-based and not feature based (we don't
>>>> communicate or promise any new features in advance) there is also no
>>>> top-down prioritization done by the PSC. It is really the developers who
>>>> decide when something is ready to be released and it is also the
>>>> developers who prioritize their work by themselves. If a customer of a
>>>> QGIS developer comes up with a new feature and new requirements, they
>>>> can consult the road map with the time line and discuss with their
>>>> developer to find out what release date can be realistically targeted,
>>>> taking into account time for preparation, discussion of QEP (QGIS
>>>> enhancement proposal), development time, testing and bug fixing.
>>>>
>>>> What methodology do you use to prioritise features within your next
>>>> release?
>>>> These are some of the most common methods for prioritising features, do
>>>> you use one of them? If not please describe how you prioritise features.
>>>>
>>>>  * Kano (Delighters, Satisfiers, Basic Expectations)
>>>>  * MoSCoW (Must, Should, Could, Won't)
>>>>  * Buy a Feature (each team member gets an allocation of points and
>>>>    assign to features)
>>>>  * RICE (Reach, Impact, Confidence, Effort)
>>>>  * No formal process to prioritise features
>>>>  * Other:
>>>>
>>>>
>>>>    Requirements Capture
>>>>
>>>> How do you capture and document requirements within your project?
>>>>
>>>> Requirements
>>>> How do you identify user requirements
>>>>
>>>>  * User Stories
>>>>  * Job Stories
>>>>  * Detailed feature descriptions
>>>>  * Surveys
>>>>  * Other:
>>>>
>>>>
>>>>    I can't describe our product management process by responding to
>>>>    your questions!
>>>>
>>>> This is the pint where you can just write whatever you wish about the
>>>> product management processes in your project and include answers to the
>>>> questions that I have neglected to ask!
>>>>
>>>> Answering your way
>>>> Write whatever you wish in this section
>>>> It was a very good decision to introduce a strictly time-based road map
>>>> for QGIS and don't wait for specific features to be ready until we
>>>> release the upcoming version. Before that switch to a time-based release
>>>> schedule we had endless discussions when a new release would be ready or
>>>> not. The only exception is when we do a new major release that is
>>>> dependent on major technological changes, such as the change from QGIS 1
>>>> to 2, or 2 to 3, where a lot of technical changes happened under the
>>>> hood (e.g. switching qt version or Python version, API changes, etc.).
>>>> In such a major change everything has to work as expected and it is very
>>>> hard to predict when everything is ready. The other convention we have
>>>> is, that during a major release cycle, the API has to remain stable. API
>>>> changes are only allowed when a new major QGIS version is prepared. We
>>>> often work as a "do-ocracy". Many tasks and development work are picked
>>>> up by contributors or developers as they see the need and can contribute
>>>> resources. Coordination happens on regular PSC meetings (monthly),
>>>> bi-annual developer meetings and through Github and mailing lists or on
>>>> IRC. The "bottom up" process regarding new features and their
>>>> prioritization usually works fine for us currently - it gives the
>>>> users/funders/developers a lot of freedom to decide when something can
>>>> get into a future QGIS version. They are not at the mercy of a product
>>>> management team or of the PSC who would decide on what gets into QGIS or
>>>> not. So the power is at the users/funders and developers and not with
>>>> the PSC and board. Should something really controversial come up during
>>>> the process, we have an established voting system consisting of
>>>> community voting members, user groups voting members and an OSGEO
>>>> representative. We don't / can't work like a classical software company,
>>>> because QGIS developers are not the employees of QGIS.ORG
>>>> <http://QGIS.ORG>
>>>> <http://QGIS.ORG>, but are individual developers, volunteers or
>>>> employees from support and development companies who work independent of
>>>> QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG>, but collaborate under
>>>> the umbrella of
>>>> QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG>. In this setup of our
>>>> organization we can't
>>>> dictate or enforce rules and decisions on our contributors and
>>>> developers but have to work out compromises and convince the
>>>> contributors to accept the proposals by the community, PSC and board.
>>>> TODO: QGIS as a project certainly has some weak points we should improve
>>>> in our organization and release process and project management. We
>>>> should come up with a common and clear vision. Quality assurance is
>>>> always a challenge and most of our donations and sustaining membership
>>>> contributions go into bug fixing and improving our code quality and
>>>> testing.
>>>>
>>>>
>>>>    The last bit
>>>>
>>>> A few questions about the organisation of product management within your
>>>> project, your analysis of your competitors and your communications with
>>>> your users.
>>>>
>>>> How do product management decisions sit within your project's
>>>> organisation?
>>>> Who makes the decisions?
>>>>
>>>>  * Project Steering Committee
>>>>  * A Product Management sub-committee
>>>>  * The contributors decide
>>>>  * Other:
>>>>
>>>>
>>>> Do you track what your competitors are doing?
>>>>
>>>>  * Yes
>>>>  * No
>>>>  * We don't have any competitors
>>>>  * Other:
>>>>
>>>>
>>>> How do you track competitor developments?
>>>> If you are tracking competitor developments how do you do so? If not,
>>>> can you explain why this is not a consideration in determining the
>>>> direction of your project?
>>>> If our contributors and funders think that some competitor
>>>> project/product offers something we don't have, or does something than
>>>> we do, they can bring ideas to the table and if it is important to them,
>>>> they will invest (time and/or financial resources) to add these missing
>>>> pieces or improve our software and project.
>>>>
>>>> Do end users get a say on the roadmap?
>>>> Do you have a channel for dialogue with your users? How do you reach
>>>> them and how important is their input in determining your roadmap?
>>>> Yes, definitely. We have votes on QGIS grant proposals and with their
>>>> investments (time and money) they can decide what gets into QGIS or not.
>>>>
>>>> Any last thoughts?
>>>> Anything I haven't asked you that you would like to share
>>>>
>>>> Create your own Google Form
>>>> <https://docs.google.com/forms?usp=mail_form_link>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --
>>>> Andreas Neumann
>>>> QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG> board member (treasurer)
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
> --
> Open Source GIS Expert / Water management
>
> mail: [hidden email]
> tél: 0033 184 257 870
> ---------------------------------
> http://oslandia.com/
>
> OSLANDIA IS AN INNOVATIVE COMPANY SPECIALIZED IN GIS ARCHITECTURE. WE
> PROVIDE SERVICE ON OPEN SOURCE SOFTWARE FOR WHICH WE ARE EDITORS OR
> RECOGNIZED EXPERTS.
>
>
> _______________________________________________
> 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: Fwd: Product management processes in OSGeo projects

Tim Sutton-6
Hi

On 19 Jun 2019, at 06:10, Paolo Cavallini <[hidden email]> wrote:

Hi all,
Tim proposal implies a budget in the order of a few million
dollars/euros. Does anybody have ideas about large donors to approach?

Just bear in mind it is not a proposal, it is a vision. 

"vision statement describes where the companyaspires to be upon achieving its mission. This statement reveals the "where" of a business -- but not just where the company seeks to be. Rather, a vision statement describes where the companywants a community, or the world, to be as a result of the company's services.


So it is a ‘high, long term thing we want to reach”. Then the goals support the vision and our day to day / month to month actions should be aligned to our goals and vision. So e.g. Andreas sustaining member programme would be something that takes us closer to achieving a sustainable income. And our decisions we make should lean towards our goals. E.g. hiring developers first as contractors until we have enough to hire them as staff, then eventually hiring offices, admin person, documentation writers etc in whatever sequence make sense.

I think not hiring Larissa was an example of where we might have taken a different decision if our vision and goals were something more aligned to what I and Regis are proposing for a vision.

Regards

Tim



Cheers.

On 11/06/19 09:41, Régis Haubourg wrote:
Hi all,

Good answers Andreas. You summarize very well the project.

I also second Tim's vision. Our vision, beyond what you wrote, is to
reach a sustainable organization able to tackle quality assessment, doc,
and get involved in GIS work-groups upstream (OGC, UN, national
workgroups via QGIS user groupes / OSGEO local Chapter).

Sustainable is a key here. We need to onboard new contributors. We need
to be more accessible (always). We need to adress students and schools.
We need happy dev's not having to do to much benevolent work (I mean
night & days & weekend is not sustainable). 

Let's keep going this way !

Régis

Le 11/06/2019 à 08:35, Tim Sutton a écrit :
Good replies Andreas!

I like your vision.

I think it would be useful to also have a vision for QGIS.org
<http://QGIS.org>. My vision has always been to have a well funded
sustainable organisation with dedicated staff that work at the
direction of the board to maintain the project infrastructure and key
resources (documentation, testing environment etc.) whilst leaving the
community to innovate and bring new features and functionality to the
project.

I also think that part of our vision should be to have a seat at the
table of major industry standards bodies so that we can help to set
the direction of the industry as a whole. Maybe this last one is
achieved by OSGEO but I think we should have more presence there as
probably the world's most used desktop GIS.

Thanks for responding to the survey Andreas!

Tim Sutton 
Co-founder of Kartoza 
Ex-QGIS project chairman 

On 9 Jun 2019, at 19:45, Paolo Cavallini <[hidden email]
<[hidden email]>> wrote:

Hi Andreas,
thanks for dealing with this.
I'm happy with your replies. Just a few comments:
* I think we do collect some usage metrics (volume of downloads on
cloudflare, hits on versions.txt, number of plugin downloads, etc.),
although I agree that none of them is sensu stricto a measure, rather an
estimate
* I can't read your replies on Roadmap, Requirements capture (Other) in
its entirety
* I think it is fair to say that we do manage our roadmap by open and
public discussion on our mailing list and PSC meetings
* I find your TODO a bit pessimistic, I believe we have to be very proud
of what the whole community has done; of course we can and will improve,
but I should not emphasize weak points: I think we have less than most
projects.
Cheers.

On 09/06/19 13:00, Andreas Neumann wrote:
Hi,

Steven Feldman conducted a survey on product management processes in
OSGeo projects. The results will be presented at the FOSS4G in Bukarest.

In agreement with Paolo, I participated on behalf of QGIS.ORG
<http://QGIS.ORG>
<http://QGIS.ORG> to submit and explain the current situation of
QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG> in this aspect.

I am forwarding the questionnaire and my replies for your review. If you
find something wrong in my statements or if I missed something
substantial, please speak up and I will send Steven a corrected version.

Thanks and greetings,
Andreas 

---------- Forwarded message ---------
From: *Google Forms* <[hidden email]
<[hidden email]>
<[hidden email]>>
Date: Sun, 9 Jun 2019 at 12:54
Subject: Product management processes in OSGeo projects
To: <[hidden email] <[hidden email]>
<[hidden email]>>


Google Forms

Thanks for filling out Product management processes in OSGeo projects
<https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
Here's what we got from you:


 Product management processes in OSGeo projects

Thank you for agreeing to help me in researching product management
processes in OSGeo projects. My aim is to try and establish:

• Does the Open Source collaborative development model incorporate and
support product management disciplines?
• Are there formal product management strategies within the OSGeo
Community?
• How is a roadmap developed?
• Is the roadmap inspired by a cohesive vision or is it driven by the
willingness of larger users to fund features?
• How do projects get to hear the voice of the user?
• Do software development methodologies impact product management?
• Are there best practices that we can learn from and share?

Following on from this survey I plan to contact some (most) of the
respondents and if you are available conduct a short interview with you
via a call or by email.

It would be great if you could complete this survey by 3rd June 2019.

I hope to present the results of this research at FOSS4G at the end of
the summer, I will also write up the results and share with our
community and others. Subject to timing I will make an early version of
my presentation/write up available to respondents for comment before
publication.

Thanks once again for your help

May the FOSS be with you

Steven


Email address *
[hidden email] <[hidden email]> <[hidden email]>


   A bit about you and your project

If you think someone else on your project steering team should be
completing this survey as well as or instead of you please forward the
survey to them

Your name *
Andreas Neumann

Project *
QGIS

What is your role in the project team?
Steering Committee Chair or Member, Contributor, Other?
PSC and board member

How long have you been active within the project team?
13 years, but only 4 years on PSC/board

Are you willing to participate in a short interview

 * Yes
 * No
 * Maybe


Best way to contact you for an interview

 * Google Hangouts
 * Skype
 * WhatsApp call
 * email
 * Other:


   Product management processes

I have set out a series of questions below that will help me to
understand how your project sets goals, converts them to a roadmap and
then prioritises features. It will make collating your response easier
if you can respond to these questions but if you find that too tedious
or if your responses don't fit with the structure of my questions then I
have given you the option of including a long form text answer at the
end of the questionnaire.


   Vision and Goals

Has your project set out a vision and a set of goals that drive the
roadmap?

Does your project have a clear statement of vision or purpose?
Why are you and others committing time to this project? What do you hope
to achieve?

 * Yes
 * No
 * Sort of


Does your project have a set of goals or targets that you are trying to
achieve?
These may be the metrics by which you can measure success,

 * Yes
 * No
 * Sort of


Do you gather any usage metrics about your project

 * Yes
 * No
 * Other:


Vision and goals
If available please paste your vision and goals in this section or add a
link to them
No official vision yet - but that reminds me that we should come up with
one and publish it. Here is one proposal (just formulated by myself and
not discussed yet with the PSC. ): To make GIS available and affordable
to anyone who is interested in using GIS, regardless of the budget and
resources they have at hand. To be a user friendly GIS for Desktop,
Server and Mobile. To be available for many platforms (Linux, Mac,
Windows, Android). Road Map and new features to be defined by active
users, funders and devlopers (bottom up and not top down). Note that
this not the official vision - just my proposal from myself and not yet
discussed and sanctioned by the PSC and voting members. I will start a
discussion to come up with a vision and goals.


   Roadmap

How do you establish and maintain the roadmap for your project?

Do you have a roadmap for your project?

 * None
 * 1 year
 * 2 year
 * 3 year
 * Other:


What methodology do you use to manage your roadmap?
These are some of the most common methods for managing a roadmap, do you
use one of them? If not please describe how you plan and communicate
your roadmap.

 * Priority Buckets (Now, Next, Later)
 * Categorize, Cluster and Communicate (e.g.
   https://library.gv.com/climbing-mount-enterprise-99a4d014f942
   <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
   )
 * 3 feature buckets (Customer requests, Metrics movers, Customer
delight)
 * No formal process to manage roadmap
 * Other:


Link to your roadmap
If you publish a roadmap please provide a link to the current version
https://www.qgis.org/en/site/getinvolved/development/roadmap.html


   Feature prioritisation

How do you prioritise features within the next release(s) of your
project?

Sponsored Features
To what extent do you prioritise features that are wholly or partly
sponsored by users of the software? Does this create any conflicts in
terms of feature prioritisation or your roadmap? Please be assured that
any responses on sponsored features will be anonymised so that your
project and sponsors will not be identified.
There is no differentiation between features that are sponsored and
features that are developed and submitted from volunteers. Because our
road map is strictly time-based and not feature based (we don't
communicate or promise any new features in advance) there is also no
top-down prioritization done by the PSC. It is really the developers who
decide when something is ready to be released and it is also the
developers who prioritize their work by themselves. If a customer of a
QGIS developer comes up with a new feature and new requirements, they
can consult the road map with the time line and discuss with their
developer to find out what release date can be realistically targeted,
taking into account time for preparation, discussion of QEP (QGIS
enhancement proposal), development time, testing and bug fixing.

What methodology do you use to prioritise features within your next
release?
These are some of the most common methods for prioritising features, do
you use one of them? If not please describe how you prioritise features.

 * Kano (Delighters, Satisfiers, Basic Expectations)
 * MoSCoW (Must, Should, Could, Won't)
 * Buy a Feature (each team member gets an allocation of points and
   assign to features)
 * RICE (Reach, Impact, Confidence, Effort)
 * No formal process to prioritise features
 * Other:


   Requirements Capture

How do you capture and document requirements within your project?

Requirements
How do you identify user requirements

 * User Stories
 * Job Stories
 * Detailed feature descriptions
 * Surveys
 * Other:


   I can't describe our product management process by responding to
   your questions!

This is the pint where you can just write whatever you wish about the
product management processes in your project and include answers to the
questions that I have neglected to ask!

Answering your way
Write whatever you wish in this section
It was a very good decision to introduce a strictly time-based road map
for QGIS and don't wait for specific features to be ready until we
release the upcoming version. Before that switch to a time-based release
schedule we had endless discussions when a new release would be ready or
not. The only exception is when we do a new major release that is
dependent on major technological changes, such as the change from QGIS 1
to 2, or 2 to 3, where a lot of technical changes happened under the
hood (e.g. switching qt version or Python version, API changes, etc.).
In such a major change everything has to work as expected and it is very
hard to predict when everything is ready. The other convention we have
is, that during a major release cycle, the API has to remain stable. API
changes are only allowed when a new major QGIS version is prepared. We
often work as a "do-ocracy". Many tasks and development work are picked
up by contributors or developers as they see the need and can contribute
resources. Coordination happens on regular PSC meetings (monthly),
bi-annual developer meetings and through Github and mailing lists or on
IRC. The "bottom up" process regarding new features and their
prioritization usually works fine for us currently - it gives the
users/funders/developers a lot of freedom to decide when something can
get into a future QGIS version. They are not at the mercy of a product
management team or of the PSC who would decide on what gets into QGIS or
not. So the power is at the users/funders and developers and not with
the PSC and board. Should something really controversial come up during
the process, we have an established voting system consisting of
community voting members, user groups voting members and an OSGEO
representative. We don't / can't work like a classical software company,
because QGIS developers are not the employees of QGIS.ORG
<http://QGIS.ORG>
<http://QGIS.ORG>, but are individual developers, volunteers or
employees from support and development companies who work independent of
QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG>, but collaborate under
the umbrella of
QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG>. In this setup of our
organization we can't
dictate or enforce rules and decisions on our contributors and
developers but have to work out compromises and convince the
contributors to accept the proposals by the community, PSC and board.
TODO: QGIS as a project certainly has some weak points we should improve
in our organization and release process and project management. We
should come up with a common and clear vision. Quality assurance is
always a challenge and most of our donations and sustaining membership
contributions go into bug fixing and improving our code quality and
testing.


   The last bit

A few questions about the organisation of product management within your
project, your analysis of your competitors and your communications with
your users.

How do product management decisions sit within your project's
organisation?
Who makes the decisions?

 * Project Steering Committee
 * A Product Management sub-committee
 * The contributors decide
 * Other:


Do you track what your competitors are doing?

 * Yes
 * No
 * We don't have any competitors
 * Other:


How do you track competitor developments?
If you are tracking competitor developments how do you do so? If not,
can you explain why this is not a consideration in determining the
direction of your project?
If our contributors and funders think that some competitor
project/product offers something we don't have, or does something than
we do, they can bring ideas to the table and if it is important to them,
they will invest (time and/or financial resources) to add these missing
pieces or improve our software and project.

Do end users get a say on the roadmap?
Do you have a channel for dialogue with your users? How do you reach
them and how important is their input in determining your roadmap?
Yes, definitely. We have votes on QGIS grant proposals and with their
investments (time and money) they can decide what gets into QGIS or not.

Any last thoughts?
Anything I haven't asked you that you would like to share

Create your own Google Form
<https://docs.google.com/forms?usp=mail_form_link>



-- 

--
Andreas Neumann
QGIS.ORG <http://QGIS.ORG> <http://QGIS.ORG> board member (treasurer)

_______________________________________________
Qgis-psc mailing list
[hidden email] <[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] <[hidden email]>
https://lists.osgeo.org/mailman/listinfo/qgis-psc

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

-- 
Open Source GIS Expert / Water management 

mail: [hidden email] 
tél: 0033 184 257 870
---------------------------------
http://oslandia.com/

OSLANDIA IS AN INNOVATIVE COMPANY SPECIALIZED IN GIS ARCHITECTURE. WE
PROVIDE SERVICE ON OPEN SOURCE SOFTWARE FOR WHICH WE ARE EDITORS OR
RECOGNIZED EXPERTS.


_______________________________________________
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

 




---

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: Fwd: Product management processes in OSGeo projects

pcav
Hi Tim, all,
I understand well your point, and although I find it very attractive and
positive, I have a different vision. Looking at most OS projects, with a
very few notable exceptions (mainly the Linux kernel comes to my mind),
they never attract large donors, if not sporadically. IMHO, for QGIS to
be sustainable over the long term we should rely more on our roots, i.e.
volunteers, and less on external resources, who put us at risk.
I'm quite happy we are making these different opinions explicit, I'm
sure this open and friendly discussion will help the project growing.
All the best.

On 19/06/19 13:25, Tim Sutton wrote:

> Hi
>
>> On 19 Jun 2019, at 06:10, Paolo Cavallini <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi all,
>> Tim proposal implies a budget in the order of a few million
>> dollars/euros. Does anybody have ideas about large donors to approach?
>
> Just bear in mind it is not a proposal, it is a vision. 
>
> "A *vision statement* describes where the *company*aspires to be upon
> achieving its *mission*. This *statement* reveals the "where" of
> a *business* -- but not just where the *company* seeks to be. Rather,
> a *vision statement* describes where the *company*wants a community, or
> the world, to be as a result of the *company's* services.”
>
> https://blog.hubspot.com/marketing/inspiring-company-mission-statements
> <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwikwqHftvXiAhWSGuwKHUvAA9AQFjACegQIDxAH&url=https%3A%2F%2Fblog.hubspot.com%2Fmarketing%2Finspiring-company-mission-statements&usg=AOvVaw1tu3zqwm_bFzQNfx-blwR5>
>
> So it is a ‘high, long term thing we want to reach”. Then the goals
> support the vision and our day to day / month to month actions should be
> aligned to our goals and vision. So e.g. Andreas sustaining member
> programme would be something that takes us closer to achieving a
> sustainable income. And our decisions we make should lean towards our
> goals. E.g. hiring developers first as contractors until we have enough
> to hire them as staff, then eventually hiring offices, admin person,
> documentation writers etc in whatever sequence make sense.
>
> I think not hiring Larissa was an example of where we might have taken a
> different decision if our vision and goals were something more aligned
> to what I and Regis are proposing for a vision.
>
> Regards
>
> Tim
>
>
>
>> Cheers.
>>
>> On 11/06/19 09:41, Régis Haubourg wrote:
>>> Hi all,
>>>
>>> Good answers Andreas. You summarize very well the project.
>>>
>>> I also second Tim's vision. Our vision, beyond what you wrote, is to
>>> reach a sustainable organization able to tackle quality assessment, doc,
>>> and get involved in GIS work-groups upstream (OGC, UN, national
>>> workgroups via QGIS user groupes / OSGEO local Chapter).
>>>
>>> Sustainable is a key here. We need to onboard new contributors. We need
>>> to be more accessible (always). We need to adress students and schools.
>>> We need happy dev's not having to do to much benevolent work (I mean
>>> night & days & weekend is not sustainable). 
>>>
>>> Let's keep going this way !
>>>
>>> Régis
>>>
>>> Le 11/06/2019 à 08:35, Tim Sutton a écrit :
>>>> Good replies Andreas!
>>>>
>>>> I like your vision.
>>>>
>>>> I think it would be useful to also have a vision for QGIS.org
>>>> <http://QGIS.org>
>>>> <http://QGIS.org <http://qgis.org/>>. My vision has always been to
>>>> have a well funded
>>>> sustainable organisation with dedicated staff that work at the
>>>> direction of the board to maintain the project infrastructure and key
>>>> resources (documentation, testing environment etc.) whilst leaving the
>>>> community to innovate and bring new features and functionality to the
>>>> project.
>>>>
>>>> I also think that part of our vision should be to have a seat at the
>>>> table of major industry standards bodies so that we can help to set
>>>> the direction of the industry as a whole. Maybe this last one is
>>>> achieved by OSGEO but I think we should have more presence there as
>>>> probably the world's most used desktop GIS.
>>>>
>>>> Thanks for responding to the survey Andreas!
>>>>
>>>> Tim Sutton 
>>>> Co-founder of Kartoza 
>>>> Ex-QGIS project chairman 
>>>>
>>>> On 9 Jun 2019, at 19:45, Paolo Cavallini <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>> Hi Andreas,
>>>>> thanks for dealing with this.
>>>>> I'm happy with your replies. Just a few comments:
>>>>> * I think we do collect some usage metrics (volume of downloads on
>>>>> cloudflare, hits on versions.txt, number of plugin downloads, etc.),
>>>>> although I agree that none of them is sensu stricto a measure,
>>>>> rather an
>>>>> estimate
>>>>> * I can't read your replies on Roadmap, Requirements capture (Other) in
>>>>> its entirety
>>>>> * I think it is fair to say that we do manage our roadmap by open and
>>>>> public discussion on our mailing list and PSC meetings
>>>>> * I find your TODO a bit pessimistic, I believe we have to be very
>>>>> proud
>>>>> of what the whole community has done; of course we can and will
>>>>> improve,
>>>>> but I should not emphasize weak points: I think we have less than most
>>>>> projects.
>>>>> Cheers.
>>>>>
>>>>> On 09/06/19 13:00, Andreas Neumann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Steven Feldman conducted a survey on product management processes in
>>>>>> OSGeo projects. The results will be presented at the FOSS4G in
>>>>>> Bukarest.
>>>>>>
>>>>>> In agreement with Paolo, I participated on behalf of QGIS.ORG
>>>>>> <http://qgis.org/>
>>>>>> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>> to submit and explain the
>>>>>> current situation of
>>>>>> QGIS.ORG <http://qgis.org/> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>> in this aspect.
>>>>>>
>>>>>> I am forwarding the questionnaire and my replies for your review.
>>>>>> If you
>>>>>> find something wrong in my statements or if I missed something
>>>>>> substantial, please speak up and I will send Steven a corrected
>>>>>> version.
>>>>>>
>>>>>> Thanks and greetings,
>>>>>> Andreas 
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: *Google Forms* <[hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>>
>>>>>> Date: Sun, 9 Jun 2019 at 12:54
>>>>>> Subject: Product management processes in OSGeo projects
>>>>>> To: <[hidden email]
>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>>
>>>>>>
>>>>>>
>>>>>> Google Forms
>>>>>>
>>>>>> Thanks for filling out Product management processes in OSGeo projects
>>>>>> <https://docs.google.com/forms/d/e/1FAIpQLSepJf73WAxem6lxBCY0grv4KGln3M0frmIW0fgoM-injyn8YA/viewform?usp=mail_form_link>
>>>>>> Here's what we got from you:
>>>>>>
>>>>>>
>>>>>>  Product management processes in OSGeo projects
>>>>>>
>>>>>> Thank you for agreeing to help me in researching product management
>>>>>> processes in OSGeo projects. My aim is to try and establish:
>>>>>>
>>>>>> • Does the Open Source collaborative development model incorporate and
>>>>>> support product management disciplines?
>>>>>> • Are there formal product management strategies within the OSGeo
>>>>>> Community?
>>>>>> • How is a roadmap developed?
>>>>>> • Is the roadmap inspired by a cohesive vision or is it driven by the
>>>>>> willingness of larger users to fund features?
>>>>>> • How do projects get to hear the voice of the user?
>>>>>> • Do software development methodologies impact product management?
>>>>>> • Are there best practices that we can learn from and share?
>>>>>>
>>>>>> Following on from this survey I plan to contact some (most) of the
>>>>>> respondents and if you are available conduct a short interview
>>>>>> with you
>>>>>> via a call or by email.
>>>>>>
>>>>>> It would be great if you could complete this survey by 3rd June 2019.
>>>>>>
>>>>>> I hope to present the results of this research at FOSS4G at the end of
>>>>>> the summer, I will also write up the results and share with our
>>>>>> community and others. Subject to timing I will make an early
>>>>>> version of
>>>>>> my presentation/write up available to respondents for comment before
>>>>>> publication.
>>>>>>
>>>>>> Thanks once again for your help
>>>>>>
>>>>>> May the FOSS be with you
>>>>>>
>>>>>> Steven
>>>>>>
>>>>>>
>>>>>> Email address *
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>
>>>>>>
>>>>>>
>>>>>>    A bit about you and your project
>>>>>>
>>>>>> If you think someone else on your project steering team should be
>>>>>> completing this survey as well as or instead of you please forward the
>>>>>> survey to them
>>>>>>
>>>>>> Your name *
>>>>>> Andreas Neumann
>>>>>>
>>>>>> Project *
>>>>>> QGIS
>>>>>>
>>>>>> What is your role in the project team?
>>>>>> Steering Committee Chair or Member, Contributor, Other?
>>>>>> PSC and board member
>>>>>>
>>>>>> How long have you been active within the project team?
>>>>>> 13 years, but only 4 years on PSC/board
>>>>>>
>>>>>> Are you willing to participate in a short interview
>>>>>>
>>>>>>  * Yes
>>>>>>  * No
>>>>>>  * Maybe
>>>>>>
>>>>>>
>>>>>> Best way to contact you for an interview
>>>>>>
>>>>>>  * Google Hangouts
>>>>>>  * Skype
>>>>>>  * WhatsApp call
>>>>>>  * email
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>>    Product management processes
>>>>>>
>>>>>> I have set out a series of questions below that will help me to
>>>>>> understand how your project sets goals, converts them to a roadmap and
>>>>>> then prioritises features. It will make collating your response easier
>>>>>> if you can respond to these questions but if you find that too tedious
>>>>>> or if your responses don't fit with the structure of my questions
>>>>>> then I
>>>>>> have given you the option of including a long form text answer at the
>>>>>> end of the questionnaire.
>>>>>>
>>>>>>
>>>>>>    Vision and Goals
>>>>>>
>>>>>> Has your project set out a vision and a set of goals that drive the
>>>>>> roadmap?
>>>>>>
>>>>>> Does your project have a clear statement of vision or purpose?
>>>>>> Why are you and others committing time to this project? What do
>>>>>> you hope
>>>>>> to achieve?
>>>>>>
>>>>>>  * Yes
>>>>>>  * No
>>>>>>  * Sort of
>>>>>>
>>>>>>
>>>>>> Does your project have a set of goals or targets that you are
>>>>>> trying to
>>>>>> achieve?
>>>>>> These may be the metrics by which you can measure success,
>>>>>>
>>>>>>  * Yes
>>>>>>  * No
>>>>>>  * Sort of
>>>>>>
>>>>>>
>>>>>> Do you gather any usage metrics about your project
>>>>>>
>>>>>>  * Yes
>>>>>>  * No
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>> Vision and goals
>>>>>> If available please paste your vision and goals in this section or
>>>>>> add a
>>>>>> link to them
>>>>>> No official vision yet - but that reminds me that we should come
>>>>>> up with
>>>>>> one and publish it. Here is one proposal (just formulated by
>>>>>> myself and
>>>>>> not discussed yet with the PSC. ): To make GIS available and
>>>>>> affordable
>>>>>> to anyone who is interested in using GIS, regardless of the budget and
>>>>>> resources they have at hand. To be a user friendly GIS for Desktop,
>>>>>> Server and Mobile. To be available for many platforms (Linux, Mac,
>>>>>> Windows, Android). Road Map and new features to be defined by active
>>>>>> users, funders and devlopers (bottom up and not top down). Note that
>>>>>> this not the official vision - just my proposal from myself and
>>>>>> not yet
>>>>>> discussed and sanctioned by the PSC and voting members. I will start a
>>>>>> discussion to come up with a vision and goals.
>>>>>>
>>>>>>
>>>>>>    Roadmap
>>>>>>
>>>>>> How do you establish and maintain the roadmap for your project?
>>>>>>
>>>>>> Do you have a roadmap for your project?
>>>>>>
>>>>>>  * None
>>>>>>  * 1 year
>>>>>>  * 2 year
>>>>>>  * 3 year
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>> What methodology do you use to manage your roadmap?
>>>>>> These are some of the most common methods for managing a roadmap,
>>>>>> do you
>>>>>> use one of them? If not please describe how you plan and communicate
>>>>>> your roadmap.
>>>>>>
>>>>>>  * Priority Buckets (Now, Next, Later)
>>>>>>  * Categorize, Cluster and Communicate (e.g.
>>>>>>    https://library.gv.com/climbing-mount-enterprise-99a4d014f942
>>>>>>    <https://www.google.com/url?q=https://library.gv.com/climbing-mount-enterprise-99a4d014f942&sa=D&ust=1560081262829000&usg=AFQjCNFN8mtLoU2IhOvFgyYVukyB-1hUOw>
>>>>>>    )
>>>>>>  * 3 feature buckets (Customer requests, Metrics movers, Customer
>>>>>> delight)
>>>>>>  * No formal process to manage roadmap
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>> Link to your roadmap
>>>>>> If you publish a roadmap please provide a link to the current version
>>>>>> https://www.qgis.org/en/site/getinvolved/development/roadmap.html
>>>>>>
>>>>>>
>>>>>>    Feature prioritisation
>>>>>>
>>>>>> How do you prioritise features within the next release(s) of your
>>>>>> project?
>>>>>>
>>>>>> Sponsored Features
>>>>>> To what extent do you prioritise features that are wholly or partly
>>>>>> sponsored by users of the software? Does this create any conflicts in
>>>>>> terms of feature prioritisation or your roadmap? Please be assured
>>>>>> that
>>>>>> any responses on sponsored features will be anonymised so that your
>>>>>> project and sponsors will not be identified.
>>>>>> There is no differentiation between features that are sponsored and
>>>>>> features that are developed and submitted from volunteers. Because our
>>>>>> road map is strictly time-based and not feature based (we don't
>>>>>> communicate or promise any new features in advance) there is also no
>>>>>> top-down prioritization done by the PSC. It is really the
>>>>>> developers who
>>>>>> decide when something is ready to be released and it is also the
>>>>>> developers who prioritize their work by themselves. If a customer of a
>>>>>> QGIS developer comes up with a new feature and new requirements, they
>>>>>> can consult the road map with the time line and discuss with their
>>>>>> developer to find out what release date can be realistically targeted,
>>>>>> taking into account time for preparation, discussion of QEP (QGIS
>>>>>> enhancement proposal), development time, testing and bug fixing.
>>>>>>
>>>>>> What methodology do you use to prioritise features within your next
>>>>>> release?
>>>>>> These are some of the most common methods for prioritising
>>>>>> features, do
>>>>>> you use one of them? If not please describe how you prioritise
>>>>>> features.
>>>>>>
>>>>>>  * Kano (Delighters, Satisfiers, Basic Expectations)
>>>>>>  * MoSCoW (Must, Should, Could, Won't)
>>>>>>  * Buy a Feature (each team member gets an allocation of points and
>>>>>>    assign to features)
>>>>>>  * RICE (Reach, Impact, Confidence, Effort)
>>>>>>  * No formal process to prioritise features
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>>    Requirements Capture
>>>>>>
>>>>>> How do you capture and document requirements within your project?
>>>>>>
>>>>>> Requirements
>>>>>> How do you identify user requirements
>>>>>>
>>>>>>  * User Stories
>>>>>>  * Job Stories
>>>>>>  * Detailed feature descriptions
>>>>>>  * Surveys
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>>    I can't describe our product management process by responding to
>>>>>>    your questions!
>>>>>>
>>>>>> This is the pint where you can just write whatever you wish about the
>>>>>> product management processes in your project and include answers
>>>>>> to the
>>>>>> questions that I have neglected to ask!
>>>>>>
>>>>>> Answering your way
>>>>>> Write whatever you wish in this section
>>>>>> It was a very good decision to introduce a strictly time-based
>>>>>> road map
>>>>>> for QGIS and don't wait for specific features to be ready until we
>>>>>> release the upcoming version. Before that switch to a time-based
>>>>>> release
>>>>>> schedule we had endless discussions when a new release would be
>>>>>> ready or
>>>>>> not. The only exception is when we do a new major release that is
>>>>>> dependent on major technological changes, such as the change from
>>>>>> QGIS 1
>>>>>> to 2, or 2 to 3, where a lot of technical changes happened under the
>>>>>> hood (e.g. switching qt version or Python version, API changes, etc.).
>>>>>> In such a major change everything has to work as expected and it
>>>>>> is very
>>>>>> hard to predict when everything is ready. The other convention we have
>>>>>> is, that during a major release cycle, the API has to remain
>>>>>> stable. API
>>>>>> changes are only allowed when a new major QGIS version is prepared. We
>>>>>> often work as a "do-ocracy". Many tasks and development work are
>>>>>> picked
>>>>>> up by contributors or developers as they see the need and can
>>>>>> contribute
>>>>>> resources. Coordination happens on regular PSC meetings (monthly),
>>>>>> bi-annual developer meetings and through Github and mailing lists
>>>>>> or on
>>>>>> IRC. The "bottom up" process regarding new features and their
>>>>>> prioritization usually works fine for us currently - it gives the
>>>>>> users/funders/developers a lot of freedom to decide when something can
>>>>>> get into a future QGIS version. They are not at the mercy of a product
>>>>>> management team or of the PSC who would decide on what gets into
>>>>>> QGIS or
>>>>>> not. So the power is at the users/funders and developers and not with
>>>>>> the PSC and board. Should something really controversial come up
>>>>>> during
>>>>>> the process, we have an established voting system consisting of
>>>>>> community voting members, user groups voting members and an OSGEO
>>>>>> representative. We don't / can't work like a classical software
>>>>>> company,
>>>>>> because QGIS developers are not the employees of QGIS.ORG
>>>>>> <http://qgis.org/>
>>>>>> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>>, but are individual
>>>>>> developers, volunteers or
>>>>>> employees from support and development companies who work
>>>>>> independent of
>>>>>> QGIS.ORG <http://qgis.org/> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>>, but collaborate under
>>>>>> the umbrella of
>>>>>> QGIS.ORG <http://qgis.org/> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>>. In this setup of our
>>>>>> organization we can't
>>>>>> dictate or enforce rules and decisions on our contributors and
>>>>>> developers but have to work out compromises and convince the
>>>>>> contributors to accept the proposals by the community, PSC and board.
>>>>>> TODO: QGIS as a project certainly has some weak points we should
>>>>>> improve
>>>>>> in our organization and release process and project management. We
>>>>>> should come up with a common and clear vision. Quality assurance is
>>>>>> always a challenge and most of our donations and sustaining membership
>>>>>> contributions go into bug fixing and improving our code quality and
>>>>>> testing.
>>>>>>
>>>>>>
>>>>>>    The last bit
>>>>>>
>>>>>> A few questions about the organisation of product management
>>>>>> within your
>>>>>> project, your analysis of your competitors and your communications
>>>>>> with
>>>>>> your users.
>>>>>>
>>>>>> How do product management decisions sit within your project's
>>>>>> organisation?
>>>>>> Who makes the decisions?
>>>>>>
>>>>>>  * Project Steering Committee
>>>>>>  * A Product Management sub-committee
>>>>>>  * The contributors decide
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>> Do you track what your competitors are doing?
>>>>>>
>>>>>>  * Yes
>>>>>>  * No
>>>>>>  * We don't have any competitors
>>>>>>  * Other:
>>>>>>
>>>>>>
>>>>>> How do you track competitor developments?
>>>>>> If you are tracking competitor developments how do you do so? If not,
>>>>>> can you explain why this is not a consideration in determining the
>>>>>> direction of your project?
>>>>>> If our contributors and funders think that some competitor
>>>>>> project/product offers something we don't have, or does something than
>>>>>> we do, they can bring ideas to the table and if it is important to
>>>>>> them,
>>>>>> they will invest (time and/or financial resources) to add these
>>>>>> missing
>>>>>> pieces or improve our software and project.
>>>>>>
>>>>>> Do end users get a say on the roadmap?
>>>>>> Do you have a channel for dialogue with your users? How do you reach
>>>>>> them and how important is their input in determining your roadmap?
>>>>>> Yes, definitely. We have votes on QGIS grant proposals and with their
>>>>>> investments (time and money) they can decide what gets into QGIS
>>>>>> or not.
>>>>>>
>>>>>> Any last thoughts?
>>>>>> Anything I haven't asked you that you would like to share
>>>>>>
>>>>>> Create your own Google Form
>>>>>> <https://docs.google.com/forms?usp=mail_form_link>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> --
>>>>>> Andreas Neumann
>>>>>> QGIS.ORG <http://qgis.org/> <http://QGIS.ORG <http://qgis.org/>>
>>>>>> <http://QGIS.ORG <http://qgis.org/>> board member (treasurer)
>>>>>>
>>>>>> _______________________________________________
>>>>>> Qgis-psc mailing list
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>>>>
>>>>>
>>>>> -- 
>>>>> Paolo Cavallini - www.faunalia.eu
>>>>> <http://www.faunalia.eu/> <http://www.faunalia.eu
>>>>> <http://www.faunalia.eu/>>
>>>>> QGIS.ORG <http://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]>
>>>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>>
>>>> _______________________________________________
>>>> Qgis-psc mailing list
>>>> [hidden email] <mailto:[hidden email]>
>>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>> -- 
>>> Open Source GIS Expert / Water management 
>>>
>>> mail: [hidden email] <mailto:[hidden email]
>>> tél: 0033 184 257 870
>>> ---------------------------------
>>> http://oslandia.com/
>>>
>>> OSLANDIA IS AN INNOVATIVE COMPANY SPECIALIZED IN GIS ARCHITECTURE. WE
>>> PROVIDE SERVICE ON OPEN SOURCE SOFTWARE FOR WHICH WE ARE EDITORS OR
>>> RECOGNIZED EXPERTS.
>>>
>>>
>>> _______________________________________________
>>> Qgis-psc mailing list
>>> [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
>
>  
>
>
>
>
> ---
>
> *Tim Sutton*
> [hidden email] <mailto:[hidden email]>
>
>
>
>

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