<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 25/04/2025 00:34, Vedran Stojnović
via QGIS-PSC wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div>Hi Regis and Richard,</div>
<div><br>
</div>
<div>thank you very much for your comments. I think that you
slightly misunderstood the point what I am trying to say. Let
me try to explain better:</div>
</div>
</blockquote>
<p>I think I did understand your point, which is try to take benefit
of a major release to open discussions on massive changes. <br>
I think this is not how QGIS4 has been planned. We are mainly
upgrading to Qt6 and dealing with the impacts of this on plugins
and python bindings + a few features that already were in the
classical developpement workflow, through private funding,
benevolent work, or Grant Proposal program. <br>
</p>
<p>But my point is that it is always time to discuss any matter you
feel necessary, we have quite a continuous development workflow.
<br>
Yes, we have an endless issue and feature requests list. This does
not mean they are forgotten. Any idea should be filed as a feature
request for later reference. Any issue should be filed also ( of
course, triple search before to not create duplicate). <br>
</p>
<p>But this doesn't mean things will happen by themselves. We don't
have billionaire funder behind us, so the questions always end in
finding ressources to make things happen. <br>
</p>
<p>- you have something critical for your organization ? First
discuss it, check if you are alone or not. If you can, try to get
fundings in your organization, which means explain again and again
that free software is not free, and every professional tool used
to create value should be backed by budgets, so that you can act
when facing a blocker situation, or engage ressources to improve
things in the long run. <br>
</p>
<p>- Your organisation is too small or can't afford this ? You can
engage in a local user group and get funds to make things happen,
like the Swiss , Deutch, French (and more) user groups are doing.
<br>
</p>
<p>- You always can fund QGIS.org, directly AND/OR through a local
user group / AND/OR through you organization. This will fund grant
proposal and bugfix programs. You can't target your funds, but
you can discuss upstream to make Grant proposal happen, and vote
for it through your user group. <br>
</p>
<p>- You can commit yourself to coding yourself of course. It is
quite an involvement these days given the code base and quality
standards we have, but not impossible and very encouraged ! <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>
We aren't short on time to implement my examples/proposals,
but we are short on time to define <b>the concept of a way to
propose breaking changes for the next major release </b>(assuming
we want to have it for 4.0) and only then, possibly, discuss
and implement some of these changes that I noted - <b>but
that's another topic</b>.</div>
</div>
</blockquote>
<p>There is no real hurry in fact. The annoucement of QGIS4 falsely
created to feeling, but QGIS is a rolling release. Yes, we will
pause a bit to help in QT4 transition, and the queue of features
will pile up a bit, but it won't stop. <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>The examples that I gave are some things that <b>I would</b>
<b>propose</b> (through a new system)<b> </b>as a
fundamental/breaking change - and they are coming from my
experience mostly as a QGIS user, QGIS instructor and GIS
implementer, not as a QGIS developer/contributor.</div>
<div><br>
</div>
<div>Some changes, feature requests and bug-fixes make sense
only on a major release and I think that they do not fit well
as QEP.</div>
<div>But these proposed fundamental/breaking changes should
definitely be (in my opinion):</div>
<div>1) discussed by bigger audience - to see others point of
view on same change, because QGIS covers many fields of use,</div>
<div>2) reviewed and commented by core developers,</div>
<div>3) approved by someone from PSC,</div>
<div>[ 4) ] optionally, but not obligatorily, funded by QGIS
organization - for important changes that need more work</div>
</div>
</blockquote>
<p>Agreed. I myself still have ideas from 10 years ago that didn't
happen. But the critical things I badly needed happened. Either
because I got involved to have the discussion happen, on the
lists, issues, real world events, phone calls to developers to get
real insights, and via fundings. <br>
I don't have the skills to code, so I focused in helping
coordinating some events, gather funds, translate things,
communicate. <br>
</p>
<p>So go ahead, please start separate threads for each idea you
have. Some will be seeds for the future and won't grow by
themselves. Some are quick wins that will happen because a magical
elf will be reviewing the exact part of the code base at the
moment he reads this threads. <br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>We have a concept of QEP which functions well, but I see
QEP as a proposal for new cutting edge feature implementation
that hasn't existed yet, which will bring it's own new
possibilities and bugs.</div>
<div>Other problem with QEP is that it's targeted to developers.
Developers/companies propose a new feature and implementation
details and then themselves do the work and implement proposed
feature. But, what if I'm not a C++ developer?</div>
<div>What if I do not know at all how to implement a change? But
I use QGIS everyday and I do know, from personal experience
with QGIS and other GIS related software that something isn't
implemented how it should be, or can be changed in a way that
better suits end users.*</div>
</div>
</blockquote>
<p>QEP are like Requests for Comments, a place to propose changes.
As always, very generic discussions won't trigger real work. So a
successful QEP must be backed by a dedicated analysis, developpers
will quickly jump to implementation questions and stress you out
there. I already had pure UX ideas in mind, but no idea how to
implement them. You can launch the discussion, and hire someone to
help you write a QEP that become of real proof of concept.
Selective masking was done this way, idea first, then POC
implementation, failure, another POC implementation, then core
implementation. Swiss user group, and Andreas pushed hard to make
things happen. <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Of course, we can make a feature request as an issue on
GitHub, but if it's a breaking change no one will implement it
because it will break automated workflows, existing models,
scripts and so on for who knows how many users...</div>
</div>
</blockquote>
<p>If a feature request breaks thing, it should be written with a
QEP. Migration already have been done when bringing massive
changes. I remember labeling engine changes, symbology changes
that had migration code embedded. <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div>My opinion is that this approach only pushes this feature
request to a "issues graveyard". Two of these examples are
#29100 and #54509 - they are definitely implementation
mistakes and both of them should be fixed, but who dares to
make such a change when current implementation is present for
who knows how much time.</div>
<div>If you ask me, the only right time for these changes is on
a major version change and these changes should be properly
documented so that users can have easier/non frustrating
transition to a new version.</div>
</div>
</blockquote>
<p>Issue graveyard is the symptom of the gap between the real
success of QGIS, and the number of users, facing the very small
pound of contributors ( € & worksforce ). Triaging thousands
of issues is a massive work, you can't blame the community to not
be able to cope with that flood. With more fundings, we will be
bale to hire permanent staff to triage this, just like we are
currently doing with infrastructure, website, documentation. <br>
</p>
<p>I understand your expectations in terms of quality and experience
for a version change. This is why we don't trigger the "massive"
QGIS 4 rebuilt. Let's tackle things that can be achieved. <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>I believe other users and developers have more examples
like this and that's my point with this email - to agree on
concept for proposing breaking changes and to make them
visible and discuss-able.</div>
<div>Should it be like QEP process, or just a label and
milestone mark in GitHub issues...??? We're only 6 months away
from major update, but there is no 4.0 Milestone on GitHub,
additional to that we have only one label that marks breaking
change and that is "API Break!".</div>
</div>
</blockquote>
We don't use a product owner agile sprint planning. You could
propose this. That would maybe help in displaying a roadmap where it
is easier to show in advanced what should make it to a new release.
<br>
<p>As we are having a fixed date release, currently you see what
makes it into a release when the release is tagged. It is really
hard to know this before hand, because we are a decentralized
community. Nobody has control on the planning of each
contributor's agenda. <br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Personally, I'm a bigger fan of a QEP process type - I
would love to see something like "QBCP" (QGIS Breaking Change
Proposal) process, e.g.:</div>
<div>- two months for collecting proposals - well described,
each proposal having it's own page</div>
<div>- one month for discussion and decisions on what to accept
/ reject / postpone till next major version</div>
<div>- two months for development sprint and preparing
documentation on accepted breaking changes in new version</div>
<div>- one month for finishing touches</div>
<div><br>
</div>
<div>Differently from QEP, the one that proposes QBCP doesn't
need to know anything about programming, just to point out
(and well describe and provide valid arguments) a breaking
change for new version. Core developers should be able to
immediately reject and close proposal if recognized as too
complicated or not doable for any reason.</div>
</div>
</blockquote>
Beware of the pandora box. Proposing changes is easy. Making them
feasable only happens by discussing with developers ( fund them if
you can, you will have more time from them), gather funds. We the
goal is clear and the implementation details clear enough, then it
is time to discuss real roadmap. <br>
Pushing a major change too soon, without knowing feasibility
probably won't happen in QGIS. Any accepted change must pass the
code review and integration test barrier. It takes commitment :) <br>
<br>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div>My only goal is to make QGIS more friendly by default and
better suited for end user. I hope that my idea is now clearer.</div>
</blockquote>
<p>It is very welcome! I'm just sharing my experience on how to make
things happen when being a end user or a GIS administrator, now
being a PSC elected member. <br>
</p>
<p>The free software model is incredible, but we are facing growth
challenge for sure. I think QGIS.org is doing great here, our
budgets keep on growing allowing for more professional service
every year, while still be community driven. We still have a lot
a 100% benevolent areas, like triage, code review, marketing,
translation, UX discussion. Let's not blame benevolent for their
hard work in the past, better to thank them, and help in getting
paid folks to go a step beyond. <br>
</p>
<blockquote type="cite"
cite="mid:CAL9iSMFxMHH-JjRNTONwhBS49HmqxtXb0eO1bz+M4KfC6z-7iw@mail.gmail.com">
<div><br>
</div>
<div>Sorry for long email and thank you for reading.</div>
</blockquote>
<p><br>
</p>
<p>With pleasure, your energy is really welcome!</p>
<p> <br>
</p>
<div id="grammalecte_menu_main_button_shadow_host"
style="width: 0px; height: 0px;"></div>
</body>
</html>