[Qgis-psc] Fwd: Product management processes in OSGeo projects
Andreas Neumann
andreas at qgis.org
Sun Jun 9 04:00:49 PDT 2019
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 <forms-receipts-noreply at google.com>
Date: Sun, 9 Jun 2019 at 12:54
Subject: Product management processes in OSGeo projects
To: <andreas at qgis.org>
[image: 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 *
andreas at qgis.org
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, 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.
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 board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20190609/9b7544f0/attachment.html>
More information about the Qgis-psc
mailing list