Re: [Qgis-developer] [Qgis-user] Stress about release plans
I´ve now been using-, bug reporting- and making tutorials for QGIS since 1.7 and I still find it difficult to make stable contributions in several ways: In this tread everyone write ‘more money’ or ‘Work together’ I want to donate time – but find it difficult to find a limited project. As everyone else I have a time consuming job, but find it both exiting and needed to be a part of this ‘movement’ What if we under Support on the front page make it easy to support in several ways: -We make a matrix for testing for users. Having a set of standard data. A platform (windows/linux/MAC) and then a list of functions to test. I´m sure we are several users who would gladly take a job like this if it is limited and organized – because we can see the job being done and developers taking over. In one of my courses I introduced this to my students – they also found it brilliant to be able to participate. - We make an addition to tutorials: Case based tutorials, where we can write a small summary/intro – incl. platform and version. Upload data and tutorial in our own form.( I don´t have time to re-write into a standard format) - We make more exposure about the donation page. It is set on the front page – Good – but also mention it for our students, users of all kind - to donate. Micro donations in the students beer-hut will be my next battle ☺ I love being a part of QGIS!!! Regards Lene Fischer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Il 23/07/2014 08:58, Lene Fischer ha scritto: I´ve now been using-, bug reporting- and making tutorials for QGIS since 1.7 and I still find it difficult to make stable contributions in several ways: In this tread everyone write ‘more money’ or ‘Work together’ I want to donate time – but find it difficult to find a limited project. As everyone else I have a time consuming job, but find it both exiting and needed to be a part of this ‘movement’ What if we under Support on the front page make it easy to support in several ways: Agreed fully: once we devise a way to make it easy, people respond quite positively. E.g. the new donate while downloading stuff is attracting an unprecedented number of small donations. Please help setting this up. I love being a part of QGIS!!! We all do, isn't it? ;) Thanks for your suggestions. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor -- Geoinformatikbüro Dassau - http://www.gbd-consult.de FOSSGIS consulting , training , support and analysis Ackerstrasse 144c , D - 40233 Düsseldorf , Germany Tel: +49-(0)211-47468178 , Mobil: +49-(0)171-4687540 -- Community Advisor - QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan On Wed, Jul 23, 2014 at 5:28 PM, Otto Dassau das...@gbd-consult.de wrote: Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor -- Geoinformatikbüro Dassau - http://www.gbd-consult.de FOSSGIS consulting , training , support and analysis Ackerstrasse 144c , D - 40233 Düsseldorf , Germany Tel: +49-(0)211-47468178 , Mobil: +49-(0)171-4687540 -- Community Advisor - QGIS Project Steering Committee ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi Nathan, thanks for the offer, but this is not the problem. After feature freeze we currently do a git log --since=date --grep='FEATURE', that's ok. And Tims changelog is also very helpful and often already fine as a beginning. The result is in the wiki: http://hub.qgis.org/wiki/17/ManualTasks But this covers not all changes we need to document nor does it usually describe the usage. We still we have to search the web, so it would be great to have a simple skeleton with a short description of all functionality of a feature from the developers, if that is possible. Maybe we can offer 2 ways. If developers write about features in their blog and describe how it works, as you do, you could just add the link somewhere where documenters can look it up. For others a simple documentation skeleton could be used as a standard. Whatever we finally use, it would be good to improve the current procedure. Regards Otto Am Wed, 23 Jul 2014 17:43:51 +1000 schrieb Nathan Woodrow madman...@gmail.com: We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan On Wed, Jul 23, 2014 at 5:28 PM, Otto Dassau das...@gbd-consult.de wrote: Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit
Re: [Qgis-developer] [Qgis-user] Stress about release plans
I think stubs from github to the visual changelog would be great. Also, it would be great if the visual changelog could some day be hosted under a qgis.org address. The visual changelog is very useful and I always point users to it after a new version was released. It looks a bit strange if the address is not on the qgis.org domain. Andreas Am 23.07.2014 07:43, schrieb Nathan Woodrow: We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
+1 2014-07-23 10:18 GMT+02:00 Andreas Neumann a.neum...@carto.net: Also, it would be great if the visual changelog could some day be hosted under a qgis.org address. The visual changelog is very useful and I always point users to it after a new version was released. It looks a bit strange if the address is not on the qgis.org domain. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi, I would prefere another solution instead of changing the releases. The documentation team is in the same situation. We are always behind the releases, but the problem I see is that there are not enough people working on the documents. At the moment we were not even able to start updating the manual for 2.4 yet :(. From my experience, we get many new features for every release because developers work together on the master source. For some reason trainers prefere starting from scratch working on her/his own documents and training material, which is ok, of course but leads into the situation Lene discribed. Here are two ideas that come to my mind: a) Trainers could combine their forces and prepair general training materials together that everybody can use and extend. All tools and the document basis is available and provided by QGIS project in the documentation repository. I know there are many people conducting trainings on QGIS, if they all work together as developers already do, we would probably be in a much better situation. b) An idea that already works for the development of QGIS features is paying some amount or percantage of each development for good documentation and training material. Many new features in QGIS are payed by customers. But usually customers and developers don't think about also spending an additional little amount to document the feature in the QGIS docs and training material. I don't know why, but that's reality. So for me, the problem is not just about changing the releases cycles. It is more about bringing documenters and trainers closer to the project again to combine their forces. And to make customers/users/developers aware, that documentation and training material is an important part of the software and should not be forgotten and maybe automatically added to an offer, if new (payed) features are added. Regards, Otto Am Tue, 22 Jul 2014 08:43:02 +0300 schrieb Micha Silver mi...@arava.co.il: I also do some short training courses using QGIS, and I fully understand and support Lene's idea. On 21/07/2014 18:35, Lene Fischer wrote: Hi, This is not a mail about bugs or issues on a special feature – just a matter of time. Right now I´m preparing a 3 week intensive GIS course at university level - looking forward to these annual events. But I get stressed when I see that there are only 94 days until next version of QGIS. Because in November I start over again with a 8 week course and in February a 3 week course, in may a 3 week course. All in all we have more than 140 students learning QGIS every year – and they are impressed of this program!!! I love getting new features in the program, but fear the work to run through every assignment, every video and being a bit unsure how the program works in the latest version on the different platforms. Small changes which I haven´t noticed and therefore unaware of. So a new version so soon gives me a lot of stress and so many hours of work – hours which could be used to ex. testing. When I ask users to download the program they take the official latest version – sometimes with bugs included… It gives an impression of an unprofessional product (not my words), it gives me- and others hard times to fix or explain. I´ve been talking to other users/administrators who has the same experience. What if we had : · A long term stable version for ex. 12 months with bugfix only · A developer version for 4 months with new features and bugfixes = Stable version with short bugfix-period = New developer…….. I do know it will give the developers more work – I do know it will cost more money – But I´m sure a lot of administrators will recommend, use and support if we get a more stable environment. So please – consider another release plan in the future. Regards Lene Fischer Associate Professor Department of Geosciences and Natural Resource Management University of Copenhagen MOB +45 40115084 l...@ign.ku.dk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
+1 with Otto, many many trainers do still almost all material from scratch, we loose a lot of good contributors, and we loose money also (as a funder). We started courses last year and pushed the will to have teachers contribute to bugtracking and contribute to open source version of the docs. This is a change for most trainers that live and gain contracts with their own material (pdf, slides...). Collaborative open source philosophy has not yet touched most of them! Our first attempt of contribution was to translate in French the QGIS tutorial. Now that we have transifex on, that sounds al lot more feasable for non dev's trainers. Anyway, we had to change a lot the manual and training course because our internal use cas is very specific. So, for generic courses, this seems reasonable as a funder to add a small amount of money for modification and translation of QGIS courses. Still, that requires english speakers, time, and a compatible schedule for QGIS doc builds.. For more specific courses, I'm more in favor of a catalog hosting them in qgis.org, with a mandatory open source licence, so that they could be freely reused. I also think that our Governement has its own training services, and could push their materials in QGIS doc infrastructure? That need some thinking for sure, maybe not pushing english as default langage for some use cases, which could allow reuse and translation only for those who need it.. Ideas on how to have trainers contribute and share, from all langages, for all kind of courses ? Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Stress-about-release-plans-tp5152191p5152393.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi Otto, You make some excellent points. Just to follow on one of them: But usually customers and developers don't think about also spending an additional little amount to document the feature in the QGIS docs and training material. I think that's a QGIS problem. I know when I get quotes for GeoServer stuff, or for our JavaScript library we use, the quote includes time spent updating the documentation. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. Cheers, Jonathan On 22 July 2014 10:10, Otto Dassau das...@gbd-consult.de wrote: Hi, I would prefere another solution instead of changing the releases. The documentation team is in the same situation. We are always behind the releases, but the problem I see is that there are not enough people working on the documents. At the moment we were not even able to start updating the manual for 2.4 yet :(. From my experience, we get many new features for every release because developers work together on the master source. For some reason trainers prefere starting from scratch working on her/his own documents and training material, which is ok, of course but leads into the situation Lene discribed. Here are two ideas that come to my mind: a) Trainers could combine their forces and prepair general training materials together that everybody can use and extend. All tools and the document basis is available and provided by QGIS project in the documentation repository. I know there are many people conducting trainings on QGIS, if they all work together as developers already do, we would probably be in a much better situation. b) An idea that already works for the development of QGIS features is paying some amount or percantage of each development for good documentation and training material. Many new features in QGIS are payed by customers. But usually customers and developers don't think about also spending an additional little amount to document the feature in the QGIS docs and training material. I don't know why, but that's reality. So for me, the problem is not just about changing the releases cycles. It is more about bringing documenters and trainers closer to the project again to combine their forces. And to make customers/users/developers aware, that documentation and training material is an important part of the software and should not be forgotten and maybe automatically added to an offer, if new (payed) features are added. Regards, Otto Am Tue, 22 Jul 2014 08:43:02 +0300 schrieb Micha Silver mi...@arava.co.il: I also do some short training courses using QGIS, and I fully understand and support Lene's idea. On 21/07/2014 18:35, Lene Fischer wrote: Hi, This is not a mail about bugs or issues on a special feature - just a matter of time. Right now I´m preparing a 3 week intensive GIS course at university level - looking forward to these annual events. But I get stressed when I see that there are only 94 days until next version of QGIS. Because in November I start over again with a 8 week course and in February a 3 week course, in may a 3 week course. All in all we have more than 140 students learning QGIS every year - and they are impressed of this program!!! I love getting new features in the program, but fear the work to run through every assignment, every video and being a bit unsure how the program works in the latest version on the different platforms. Small changes which I haven´t noticed and therefore unaware of. So a new version so soon gives me a lot of stress and so many hours of work - hours which could be used to ex. testing. When I ask users to download the program they take the official latest version - sometimes with bugs included... It gives an impression of an unprofessional product (not my words), it gives me- and others hard times to fix or explain. I´ve been talking to other users/administrators who has the same experience. What if we had : ·A long term stable version for ex. 12 months with bugfix only ·A developer version for 4 months with new features and bugfixes = Stable version with short bugfix-period = New developer I do know it will give the developers more work - I do know it will cost more money - But I´m sure a lot of administrators will recommend, use and support if we get a more stable environment. So please - consider another release plan in the future. Regards Lene Fischer Associate Professor Department of Geosciences and
Re: [Qgis-developer] [Qgis-user] Stress about release plans
+1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
+ 1 to Otto and Victor. Developers should develop, the can document some aspects of code/feature (and they already do this!) but we can not ask them to write manuals 2014-07-22 13:01 GMT+03:00 Victor Olaya vola...@gmail.com: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Except that self-evidently the current solution doesn't work well. Of the three projects I listed, QGIS has by far the worst documentation; as Otto noted, they've not even started updating for 2.4 yet. Just looking now, not a single one of the QGIS Geoalgorithms that I've ever looked at (which are I think is what Victor is referencing) have anything in the help tab. And these are a core part of the software. I appreciate developers hate writing documentation, and in fact they're often very bad at it anyway, but if other projects can do it with far fewer resources then I think QGIS should be able to manage it to, especially the commercial organisations that charge for feature development. Cheers, Jonathan On 22 July 2014 11:05, Alexander Bruy alexander.b...@gmail.com wrote: + 1 to Otto and Victor. Developers should develop, the can document some aspects of code/feature (and they already do this!) but we can not ask them to write manuals 2014-07-22 13:01 GMT+03:00 Victor Olaya vola...@gmail.com: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy -- This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Just looking now, not a single one of the QGIS Geoalgorithms that I've ever looked at (which are I think is what Victor is referencing) have anything in the help tab. And these are a core part of the software. Yes that's what I mean. But, IMHO, it's better to have that functionality there with an empty help tab, than not having it. People are using it, that's a fact. For some of them, it might be hard due to the lack of documentation. For some others, it might not be so hard, and eventually someone might contribute a help file. If those algorithms have to wait until the dev (me in that case) writes the corresponding doc before being able to add them, I can tell you that, most likely, they will never ever be added. And, since the functionality is not be there to be tested, no one else will volunteer to do it. I am not saying that this is ideal, and that developers should not write docs. I am saying that time is limited and, if we put those restrictions, we might end up rejecting a lot of interesting functionality. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Il 22/07/2014 12:41, Victor Olaya ha scritto: ... I am not saying that this is ideal, and that developers should not write docs. I am saying that time is limited and, if we put those restrictions, we might end up rejecting a lot of interesting functionality. Sorry for jumping in late. These are some of my thoughts: * of course we all love stability; the solution is to pay developers to fix bugs - nothing more, nothing less * all the same, we all love a complete and thorough documentation; see the above (and very good Otto comments), plus the fact that everybody can contribute to improve it (no need to be a developer, all the contrary in fact: newbies are often the best documenters) * cooperating on documentation writing, as Otto and Régis suggested, is certainly the best way to go; it's a pity seeing tons of tutorials, rewritten over and over, and never contributed back * documentation effort for processing modules has started, and it has been announced; if anyone is interested, it is easy to contribute, either with time or money; please refrain from complaining if you do not * we (Faunalia) also do hundreds of courses; IMHO it is the duty of the trainer to keep up to date - this is what makes courses interesting after all; IMHO, doing a course on an old version is not doing a good service, neither to trainees nor to the sw; I think explaining see, we're doing the course on the latest and greatest version - this comes with some less tested features; be patient, bugs will be fixed, probably soon, possibly paid by others is good enough * we are working on free software, not on a cracked proprietary *GIS version; IMHO is is a duty of the trainer to explain the difference to trainees, and show them how to open a ticket, and how to contribute for its solution; I do this since 2006, and many of my trainees are now contributors. All the best. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi all, On Tue, Jul 22, 2014 at 10:10 AM, Otto Dassau das...@gbd-consult.de wrote: a) Trainers could combine their forces and prepair general training materials together that everybody can use and extend. All tools and the document basis is available and provided by QGIS project in the documentation repository. I know there are many people conducting trainings on QGIS, if they all work together as developers already do, we would probably be in a much better situation. +1 Open source is not just open code. Contribution can be done in documentation and Help. Trainers should have a huge responsibility here. (Remember, no free lunches) Do we have people working on hunting and squashing Bugs and Feature Requests from Documentation and Help? https://hub.qgis.org/projects/quantum-gis/issues?query_id=81 Is it a common practice for developer to fill feature requests for Documentation and help whenever they create new features? This would still free developers to keep creating good stuff, and help others to keep track of what needs attention in Docs. Using the visual changelog and scrolling the commits messages might not be reliable enough. Alexandre Neto b) An idea that already works for the development of QGIS features is paying some amount or percantage of each development for good documentation and training material. Many new features in QGIS are payed by customers. But usually customers and developers don't think about also spending an additional little amount to document the feature in the QGIS docs and training material. I don't know why, but that's reality. So for me, the problem is not just about changing the releases cycles. It is more about bringing documenters and trainers closer to the project again to combine their forces. And to make customers/users/developers aware, that documentation and training material is an important part of the software and should not be forgotten and maybe automatically added to an offer, if new (payed) features are added. Regards, Otto Am Tue, 22 Jul 2014 08:43:02 +0300 schrieb Micha Silver mi...@arava.co.il: I also do some short training courses using QGIS, and I fully understand and support Lene's idea. On 21/07/2014 18:35, Lene Fischer wrote: Hi, This is not a mail about bugs or issues on a special feature – just a matter of time. Right now I´m preparing a 3 week intensive GIS course at university level - looking forward to these annual events. But I get stressed when I see that there are only 94 days until next version of QGIS. Because in November I start over again with a 8 week course and in February a 3 week course, in may a 3 week course. All in all we have more than 140 students learning QGIS every year – and they are impressed of this program!!! I love getting new features in the program, but fear the work to run through every assignment, every video and being a bit unsure how the program works in the latest version on the different platforms. Small changes which I haven´t noticed and therefore unaware of. So a new version so soon gives me a lot of stress and so many hours of work – hours which could be used to ex. testing. When I ask users to download the program they take the official latest version – sometimes with bugs included… It gives an impression of an unprofessional product (not my words), it gives me- and others hard times to fix or explain. I´ve been talking to other users/administrators who has the same experience. What if we had : ·A long term stable version for ex. 12 months with bugfix only ·A developer version for 4 months with new features and bugfixes = Stable version with short bugfix-period = New developer…….. I do know it will give the developers more work – I do know it will cost more money – But I´m sure a lot of administrators will recommend, use and support if we get a more stable environment. So please – consider another release plan in the future. Regards Lene Fischer Associate Professor Department of Geosciences and Natural Resource Management University of Copenhagen MOB +45 40115084 l...@ign.ku.dk ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Is it a common practice for developer to fill feature requests for Documentation and help whenever they create new features? This would still free developers to keep creating good stuff, and help others to keep track of what needs attention in Docs. Using the visual changelog and scrolling the commits messages might not be reliable enough. +1 In reading this thread I realised I don't know how communication between developers and documenters works in QGIS, but it seems to me that the previously mentioned idea of tying documentation and development together doesn't necessarily mean that developers would be required to write the documentation. (Obviously someone would but I don't see why that would have to be the dev.) I had the same thought as Alexandre about filing documentation request to have a doc team work on it? This may require QGIS to prioritize documentation differently than it currently does and that may not be the direction people want to go, but from what others have said it sounds like there might be some reason to shift current practice. Also, I was just looking at the QGIS homepage and found it quite difficult to figure out how to contribute to documentation. Am I missing something? I was expecting that contributing documentation would be one of the subheadings under Get Involved. I instead found it under Translate Translate QGIS into your language -- and then had to scroll down and find the documentation section, which hasn't been written, and click over to gtihub, which in turn includes no information on how to actually contribute. After some searching I was able to find the Manual Writing page in the wiki. It seems like a link to the wiki page would be useful on the Get Involved page somewhere as well as some information on how to contribute to other documentation like help files. andrew ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi Lene, Does Your proposal mean that those universities, which start to use QGIS and QGIS based material for education, start to support QGIS development financially and with other resources like man power for testing, fixing etc. ? Cheers, Kari On 07/21/2014 06:35 PM, Lene Fischer wrote: Hi, This is not a mail about bugs or issues on a special feature just a matter of time. Right now Im preparing a 3 week intensive GIS course at university level - looking forward to these annual events. But I get stressed when I see that there are only 94 days until next version of QGIS. Because in November I start over again with a 8 week course and in February a 3 week course, in may a 3 week course. All in all we have more than 140 students learning QGIS every year and they are impressed of this program!!! I love getting new features in the program, but fear the work to run through every assignment, every video and being a bit unsure how the program works in the latest version on the different platforms. Small changes which I havent noticed and therefore unaware of. So a new version so soon gives me a lot of stress and so many hours of work hours which could be used to ex. testing. When I ask users to download the program they take the official latest version sometimes with bugs included It gives an impression of an unprofessional product (not my words), it gives me- and others hard times to fix or explain. Ive been talking to other users/administrators who has the same experience. What if we had : A long term stable version for ex. 12 months with bugfix only A developer version for 4 months with new features and bugfixes = Stable version with short bugfix-period = New developer.. I do know it will give the developers more work I do know it will cost more money But Im sure a lot of administrators will recommend, use and support if we get a more stable environment. So please consider another release plan in the future. Regards Lene Fischer Associate Professor Department of Geosciences and Natural Resource Management University of Copenhagen MOB +45 40115084 l...@ign.ku.dk -- Kari Salovaara Hanko, Finland "Volunteers do not necessarily have the time; they just have the heart." ~ Elizabeth Andrew ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
I also do some short training courses using QGIS, and I fully understand and support Lene's idea. On 21/07/2014 18:35, Lene Fischer wrote: Hi, This is not a mail about bugs or issues on a special feature – just a matter of time. Right now I´m preparing a 3 week intensive GIS course at university level - looking forward to these annual events. But I get stressed when I see that there are only 94 days until next version of QGIS. Because in November I start over again with a 8 week course and in February a 3 week course, in may a 3 week course. All in all we have more than 140 students learning QGIS every year – and they are impressed of this program!!! I love getting new features in the program, but fear the work to run through every assignment, every video and being a bit unsure how the program works in the latest version on the different platforms. Small changes which I haven´t noticed and therefore unaware of. So a new version so soon gives me a lot of stress and so many hours of work – hours which could be used to ex. testing. When I ask users to download the program they take the official latest version – sometimes with bugs included… It gives an impression of an unprofessional product (not my words), it gives me- and others hard times to fix or explain. I´ve been talking to other users/administrators who has the same experience. What if we had : · A long term stable version for ex. 12 months with bugfix only · A developer version for 4 months with new features and bugfixes = Stable version with short bugfix-period = New developer…….. I do know it will give the developers more work – I do know it will cost more money – But I´m sure a lot of administrators will recommend, use and support if we get a more stable environment. So please – consider another release plan in the future. Regards Lene Fischer Associate Professor Department of Geosciences and Natural Resource Management University of Copenhagen MOB +45 40115084 l...@ign.ku.dk This mail was received via Mail-SeCure System. ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user This mail was received via Mail-SeCure System. -- Micha Silver GIS Consulting 052-3665918 http://www.surfaces.co.il ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
