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