[Qgis-psc] Fwd: Product management processes in OSGeo projects
Paolo Cavallini
cavallini at faunalia.it
Sun Jun 9 10:45:23 PDT 2019
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* <forms-receipts-noreply at google.com
> <mailto: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 <mailto:andreas at qgis.org>>
>
>
> 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 <mailto: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
> <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
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
More information about the Qgis-psc
mailing list