Changes between Initial Version and Version 1 of GRASSWikiVersusTracWiki


Ignore:
Timestamp:
01/27/14 08:37:17 (11 years ago)
Author:
wenzeslaus
Comment:

initial page content: two wikis and six controversies

Legend:

Unmodified
Added
Removed
Modified
  • GRASSWikiVersusTracWiki

    v1 v1  
     1= GRASS Wiki versus Trac Wiki =
     2
     3[[TOC]]
     4
     5''This page discuss what information should go to the GRASS Wiki and what to the Trac Wiki.''
     6
     7 * http://grasswiki.osgeo.org/ (GRASS Wiki, GRASS GIS Users Wiki, !MediaWiki)
     8 * https://trac.osgeo.org/grass/wiki (Trac Wiki, GRASS GIS Tracker and Wiki, !TracWiki)
     9
     10
     11== GRASS Wiki for current things ==
     12
     13The idea is that GRASS Wiki should be used just to describe things as they are. No discussions, no wishes, no proposals.
     14
     15The GRASS Wiki should be something like user added manual. It should contain specific examples with specific data. Guides how to use GRASS with some particular software, technology, service or data source. It should be a collection of use cases.
     16
     17GRASS Wiki should not contain proposals and pages serving as a notebook supporting development. Example of an inappropriate page is page Toolboxes:
     18
     19http://grasswiki.osgeo.org/grass-wiki/index.php?title=Toolboxes&oldid=18005
     20
     21The end user should not be confused by pages about things which does not exists. When he or she would come to Toolboxes page above, he or she expects to learn about what toolboxes in GRASS are not what they could be if the would be implemented in this or that way.
     22
     23
     24== Trac Wiki for developing ideas and tracking development ==
     25
     26Trac Wiki is the one which should be used to support development as it is connected more to tickets, commits and source code and in the same time, it is clear that it is something different than manual or GRASS wiki, so this could help to avoid confusion. For example, there is no point in having Single Map window idea listed among the existing wxGUI components at GRASS Wiki while the page at Trac wiki is perfectly OK:
     27
     28https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow
     29
     30
     31== Controversy: Moving pages from Trac ==
     32
     33The result of the above is also that the pages such as
     34
     35https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
     36
     37and partially also
     38
     39https://trac.osgeo.org/grass/wiki/DownloadSource
     40
     41should be moved to GRASS Wiki because they are describing things which are important to users and describes current status.
     42
     43The only pages on Trac Wiki which describes state of art should be the pages how to use Trac itself, for example:
     44
     45https://trac.osgeo.org/grass/wiki/HowToUseKeywords
     46
     47
     48== Controversy: Manpower for moving pages ==
     49
     50For the moving of pages we need the manpower which we lack according to the fact that we were not able to do any of the wikis cleanups which were already planed. However, by continuing in the current way where there are no rules what to put where, we are just creating more work for the future.
     51
     52So, we don't have to start to move pages around now, but it is advisable to keep the rules and think twice about what should be where.
     53
     54
     55== Controversy: GSoC ==
     56
     57GSoC pages are in the group of nice pages at GRASS Wiki and there is a tradition of putting them there, for example
     58
     59http://grasswiki.osgeo.org/grass-wiki/index.php?title=GRASS_SoC_Ideas_2013&oldid=18760
     60
     61However, the page lists things which could be done. Most of the ideas are not even turned into proposals, so why again, describe nonexistent things there?
     62
     63The same applies to student pages, too. For example temporal algebra has the page for developing ideas (and some temporary documentation) at the Trac Wiki:
     64
     65http://trac.osgeo.org/grass/wiki/Grass7/TemporalGISAlgebra
     66
     67That is great. However, the student notes
     68
     69http://grasswiki.osgeo.org/grass-wiki/index.php?title=GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS&oldid=19748
     70
     71are in fact developer notes which should be on Trac, too: they describe the progress, they are more or less commit messages. Why the user would be interested in this if it is not in the code, and current status is maybe completely different?
     72
     73
     74== Controversy: GRASS Wiki for development ==
     75
     76One of the biggest questions is if the pages about how to develop for GRASS should go to GRASS Wiki. The answer is yes, these pages describe how things are, so they should go GRASS wiki and not Trac Wiki because Trac Wiki which does not describe API or how to use it.
     77
     78We already converged to having "How to compile" pages on GRASS wiki (they were marked "move to trac" at one point, but not now). We also have a lot of pages about scripting there. And from scripting is just one step to programming (from bash to grass.script to pygrass/ctypes to C or wxGUI), so there is no reason to not include it on the GRASS Wiki. Moreover, where would be the line between using GUI or modules in command line and programming when Python console is the part of GUI?
     79
     80The scripting is the typical half-user half-developer topic:
     81
     82http://grasswiki.osgeo.org/grass-wiki/index.php?title=GRASS_and_Python&oldid=19726#Python_extensions_in_GRASS_GIS
     83
     84
     85== Controversy: GRASS Wiki is not manual ==
     86
     87When excited about what we can put the GRASS Wiki and making it right, we must remember the fact that we have also manual, more precisely, two manuals. So, create pages, enjoy user edits but think about the fact that the basic things should be in the manual.
     88
     89For example, see page about inputs to a module which is at the wiki:
     90
     91http://grasswiki.osgeo.org/grass-wiki/index.php?title=How_to_create_parameters_to_run_r.ros&oldid=19742
     92
     93Explanation of parameters and preparing input is certainly the basic topic which should be moved to manual. In other words, if the page on GRASS Wiki describes something so well that it is better than manual or the module is useless without the page, the page should be moved to manual.
     94
     95For things such as best practices and development, the things can be more complicated than for modules but the general pattern is clear, general things may appear at GRASS Wiki but when mature enough, they should be moved manual because otherwise GRASS Wiki would be replacing manual (and the next logical step would be to remove manual pages and programming manual).
     96
     97
     98== Controversy: Different syntax ==
     99
     100At some points it seemed that GRASS Wiki is preferred over the Trac one because the Trac wiki has different syntax. But the issue is not so bad. As a developer or power user one must deal not only with !WikiMedia syntax but also with HTML for manual pages and Doxygen for programming manual, so one syntax more (TracWiki syntax) is probably not a problem. Moreover, (Trac) WikiFormatting is need for Trac tickets and both tickes and wiki have ''Preview'' button and hopefully some day, we will see the new Trac version with live preview.