<div dir="ltr"><div dir="ltr"><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><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><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><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><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... 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><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><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><div dir="ltr"><br></div><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><div><br></div><div>Sorry for long email and thank you for reading.</div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Srdačan pozdrav / Kind regards,<div>Vedran Stojnović.</div></div></div></div>