[Qgis-developer] Re: What is "is a qgis problem"? (it was Re: [Qgis-user] Scattergram with compiled qwt5.2.0)

[Carson Farmer]

My two cents:

On Sat, Nov 7, 2009 at 11:41 AM, Agustin Lobo <alobolistas at gmail.com> wrote:
> I think this issue is equivalent to the one on having
> Mrsid and ecw support under linux. From
> a developer point of view (Jurgen), the fact that plugin Scatter plot
> does not work because of a python-qwt5 problem is not "a qgis problem".
> But from the user perspective, anything making qgis not working properly
> or not fulfilling a set of minimum operational requirements must
> be "a qgis problem".

Perhaps not a qgis "problem"... but a qgis "issue" certainly ;-)

> In this particular case, if the situation is that there is no
> python-qwt5 package able to let a given plugin work, then either
> the qgis developers accept that making an specially-tuned binary version of
> the python-qwt5 package is a TODO task, or the "qgis book of style of python
> plugins"

I think the only possibly solution is the latter... qgis devs barely
have time for qgis
issues, let alone Python-Qt problems. In fact, we are currently
working on guidelines
for Python plugins in qgis, and it will have to be up to the plugin
authors to make sure
their plugins obey these guidelines. Qgis main developers simply can't
support plugins
introduced by all plugin authors, and in fact, the author(s) of the
problem plugins
should be contacted directly (note that there are actually very few
officially supported
plugins in the official repo).

> must state that no plugins should be made relying on that package, and thus
> an alternative for the current Scatter plot plugin should be in the agenda.

In this particular case, the scatterplot plugin is really just a
contributed plugin that is
there for those who need it, but is not 'part of qgis' and as such
isn't currently on the
agenda at all. Right now I think stability of current tools (and
improvement of current
functionality) is a more important agenda item...

> In general terms, I think that the qgis developers should discuss and
> get to an agreement on whether the goal is having an operational package or a testbed
> for newer developments and proofs of concepts where reaching an
> operational reliability is not a main issue.

Certainly it is already the former... the proofs of concept and
cutting edge stuff is almost always
plugins (at least to start with), and again, plugins are something
separate to the core qgis. I
think what we are seeing quite a bit of the time is users and
contributors focusing more
on developing plugins, and the devs are focused much more on the core
libraries. This is how it
should be (in my opinion), and the fact that some plugins are unstable
is simply an artifact of the
fact that there is currently no rigorous guidelines from submitting plugins

> Both options are valid, but they are different, and users must know the
> choice.

The goal is to move towards a fully stable, operational GIS... plugins
and extra features (such as scatterplots)
are simply nice extensions at the moment..

> Users must put their effort on using QGIS, and their satisfaction is
> the main reason for QGIS to exist. With no or few users, qgis will
> decay.
Hmm, I don't think I agree with this, those new users are certainly important!
> And users do a lot of effort on using QGIS, as they often must deal
> with problems that are not present in commercial software and sometimes find,
> with frustration, that their processing chain gets interrupted
> in an step where qgis tools are not working (and the only answer they get
> is "this is solved in svn trunk". A pretty satisfactory answer for a
> developer, but a totally devastating answer for an student with his/her exercise to be
> due in 24h). For some users, this is the price to pay because they cannot afford
> paying the licenses but for some others, having several alternatives of commercial licenses
> paid as campus licenses, this is the price they pay for actively
> collaborating on a public domain tool which, they believe, will be better on the long run.
> We must all acknowledge the contribution made by developers. We must all
> acknowledge the contribution made by of users.

We must also acknowledge that QGIS is a 'work in progress'. There are
going to be many features
that are lacking, and when users submit bug reports, these features
get added (maybe not always
'right now'). We simply don't have the funding to build a fully
functional platform right off the bat. We
also have to acknowledge that QGIS is still a relatively young
project, and as it grow, the number of
users/contributors/developers will grow... meaning these features that
are lacking will start to be
added faster and faster (which I think we're already seeing).

Indeed, the contributions of all are important... but we also have to
note that developers
do not 'serve the users', they are users themselves, and are
volunteering their time to work
on things that 'they need'. If they can, they will also implement
things that other users need,
but in the end, there is only so much time in the day.

> I'm working on a web page in which I will propose a set of critical tasks
> to be accomplished by a GIS software, along with an score of operationality
> and
> comments for the specific case of QGIS on the different OS for which binary
> versions exist. Hopefully other users will add their opinions.
> In an equivalent way, I'll try to set up another page for the plugins, so
> that
> users can have a fast check on the degree of operationality of a giving
> plugin
> prior to actually installing it.

Great, this is the type of thing that helps clarify what needs to be done.
I also think it's important to acknowledge that plugins are indeed a
separate thing, and many
*are* simply proofs of concepts, *not* ready for production use. It's
up to users to tell the plugin
authors they are interested, and to support further development!

> I think that QGIS is not far from such an operational point and that
> making an effort on reaching it rather than on developing newer tools for a
> while would make a lot of sense... for users. Obviously, developers will do
> what they will be willing to do. All what users can do is telling other
> users what the situation is.

Agreed!


Carson
-- 
Carson Farmer
National Centre for Geocomputation
John Hume Building,
National University of Ireland, Maynooth,
Maynooth,
Co. Kildare,
Ireland.
www.carsonfarmer.com