Add a GMT team page and update contributor recognition model

AUTHORS.md → THANKS.md

@@ -1,22 +1,3 @@
-# The Founders
-
-GMT was conceived and designed in the late 1980s and early 1990s
-by [Paul Wessel](http://www.soest.hawaii.edu/pwessel/) and
-[Walter H.F. Smith](https://www.star.nesdis.noaa.gov/star/Smith_WHF.php).
-The two founders built and maintained GMT from version 1 through 3.
-
-# Addition of Team Members
-
-GMT 4 benefitted from numerous contributions from two new team members
-[Remko Scharroo](https://www.researchgate.net/profile/Remko_Scharroo)
-and [Joaquim Luis](http://joa-quim.pt/).
-
-GMT 5 saw major new contributions from team member Florian Wobbe.
-
-GMT 6 has benefitted from the contributions of two new team members
-[Leonardo Uieda](https://www.leouieda.com) and
-[Dongdong Tian](https://msu.edu/~tiandong/).
-
 # Supplement Contributions
 
 [Tim Henstock](https://www.southampton.ac.uk/oes/research/staff/then.page)

doc/rst/_static/style.css

@@ -121,3 +121,37 @@ h1, h2, h3, h4, h5, h6 {
 	font-weight: bold;
 	font-style: italic;
 }
+
+.team-row {
+    display: flex;
+    flex-wrap: wrap;
+}
+
+.team-card {
+    background-color: #fff;
+    background-clip: border-box;
+    border: 1px solid rgba(0,0,0,.125);
+    border-radius: 0.5rem;
+    margin: 0.25em;
+    flex: 0 1 175px;
+}
+
+.team-img {
+    border-radius: 0.5rem;
+    width: 100%;
+    height: 20vh!important;
+    object-fit: cover;
+}
+
+.team-card-body {
+    padding: 1.25rem;
+    height: 135px;
+}
+
+.team-card-text {
+    display: flex;
+    margin-block-start: 0em;
+    margin-block-end: 0.2em;
+    margin-inline-start: 0px;
+    margin-inline-end: 0px;
+}

doc/rst/source/changes.rst

@@ -449,7 +449,7 @@ summary of these changes:
    Pablo Valdés during the GMT4 era. These are now complemented by new custom
    symbols for structural geology designed by José A. Álvarez-Gómez.
 
-*  The :doc:`PSL <postscriptlight>` library no longer needs run-time files to configure the
+*  The :doc:`PSL </devdocs/postscriptlight>` library no longer needs run-time files to configure the
    list of standard fonts and character encodings, reducing the number of configure
    files required.
 
@@ -1153,7 +1153,7 @@ New Features in GMT 5
 GMT 5 represents a new branch of GMT development that mostly preserves the
 capabilities of the previous versions while adding over 200 new features
 to an already extensive bag of tricks.  Our PostScript library
-:doc:`PSL <postscriptlight>` has seen a complete rewrite as well
+:doc:`PSL </devdocs/postscriptlight>` has seen a complete rewrite as well
 and produce shorter and more compact PostScript. However, the big news
 is aimed for developers who wish to leverage GMT in their own applications.
 We have completely revamped the code base so that high-level

doc/rst/source/cookbook/features.rst

@@ -698,9 +698,9 @@ binary metafile plot systems since such files cannot easily be modified
 after they have been created. GMT programs also write many comments to
 the plot file which make it easier for users to orient themselves should
 they need to edit the file (e.g., % Start of x-axis) [16]_. All
-GMT programs create PostScript code by calling the :doc:`PSL </postscriptlight>` plot
+GMT programs create PostScript code by calling the :doc:`PSL </devdocs/postscriptlight>` plot
 library (The user may call these functions from his/her own C or FORTRAN
-plot programs. See the manual pages for :doc:`PSL </postscriptlight>` syntax). Although
+plot programs. See the manual pages for :doc:`PSL </devdocs/postscriptlight>` syntax). Although
 GMT programs can create very individualized plot code, there will
 always be cases not covered by these programs. Some knowledge of
 PostScript will enable the user to add such features directly into the

doc/rst/source/api.rst → doc/rst/source/devdocs/api.rst

@@ -35,9 +35,9 @@ environments since access to GMT tools could only be achieved via
 system calls [1]_. Consequently, all data i/o had to be done via
 temporary files. The design also prevented the GMT developers
 themselves from taking advantage of these modules directly. For
-instance, the tool :doc:`legend` needed to
-make extensive use of system calls to :doc:`plot` and
-:doc:`text` in order to plot the lines,
+instance, the tool :doc:`/legend` needed to
+make extensive use of system calls to :doc:`/plot` and
+:doc:`/text` in order to plot the lines,
 symbols and text that make up a map legend, making it a very awkward
 program to maintain.
 
@@ -53,7 +53,7 @@ program to maintain.
 Starting with GMT version 5, all standard GMT programs have been
 rewritten into separate function "modules" invoked by a single
 driver program called ``gmt.c``.
-The :doc:`gmt` executable simply calls the corresponding
+The :doc:`/gmt` executable simply calls the corresponding
 GMT modules; it is these modules that do all the work. These new
 functions have been placed in a new GMT high-level API library and can
 be called from a variety of environments (C/C++, Fortran, Julia, Python,
@@ -62,7 +62,7 @@ program ``blockmean.c`` has been reconfigured as a high-level function
 ``GMT_blockmean()``, which does the actual spatial averaging and can
 pass the result back to the calling program (or write it to file). The
 previous behavior of ``blockmean.c`` is achieved by calling ``gmt blockmean``,
-i.e., the module is now just the first argument to the :doc:`gmt` executable.
+i.e., the module is now just the first argument to the :doc:`/gmt` executable.
 For backwards compatibility with older GMT (4) scripts we optionally
 install numerous symbolic links to the gmt executable with names such
 as blockmean, plot, surface, etc.  The gmt executable is smart enough to
@@ -156,10 +156,10 @@ For the purpose of this documentation a few definitions are needed:
 
 #. "Standard GMT program" refers to one of the traditional stand-alone
    command-line executables known to all GMT users, e.g.,
-   :doc:`blockmean`, :doc:`plot`,
-   :doc:`grdimage`, etc. Prior to version 5,
+   :doc:`/blockmean`, :doc:`/plot`,
+   :doc:`/grdimage`, etc. Prior to version 5,
    these were the only GMT executables available.  In GMT 5 and up, these are
-   accessed via the :doc:`gmt` executable.
+   accessed via the :doc:`/gmt` executable.
 
 #. "\ GMT module" refers to the function in the GMT API library that
    is responsible for all the action taken by the corresponding
@@ -174,7 +174,7 @@ For the purpose of this documentation a few definitions are needed:
 #. "\ GMT plugin library" refers to a collection of one or more new custom
    GMT-like modules that are presented as a plugin library.  It such libraries
    are placed in the official GMT plugin directory or their path is added to
-   the GMT defaults parameter :term:`GMT_CUSTOM_LIBS` then the :doc:`gmt` executable can find them.
+   the GMT defaults parameter :term:`GMT_CUSTOM_LIBS` then the :doc:`/gmt` executable can find them.
 
 #. "Family" refers to one of the many high-level GMT data types (e.g., grids, CPTs)
    and is typically a required argument to some API functions.
@@ -193,11 +193,11 @@ For the purpose of this documentation a few definitions are needed:
    expects.
 
 In version 5, the standard GMT programs are themselves simple invocations
-of the :doc:`gmt` application with the function name as argument.
+of the :doc:`/gmt` application with the function name as argument.
 However, some of these modules, such as
-:doc:`legend`, :doc:`gmtconvert`,
-:doc:`grdblend`,
-:doc:`grdfilter` and others may call several additional modules.
+:doc:`/legend`, :doc:`/gmtconvert`,
+:doc:`/grdblend`,
+:doc:`/grdfilter` and others may call several additional modules.
 
 API changes from GMT5 to GMT 6
 ------------------------------
@@ -382,15 +382,15 @@ GMT images
 
 GMT images are used to represent bit-mapped images typically obtained
 via the GDAL bridge. These can be reprojected internally, such as when
-used in :doc:`grdimage`. Since images and grids share the concept of a header,
+used in :doc:`/grdimage`. Since images and grids share the concept of a header,
 we use the same header structure for grids as for images; however, some
 additional metadata attributes are also needed. Finally, the image
 itself may be of any data type and have more than one band (channel).
 Both image and header information are passed via a ``struct`` :ref:`GMT_IMAGE <struct-image>`,
 which is a container that holds both items. Thus, the arguments to
 GMT API functions that handle GMT images expect this type of
 variable. Unlike the other objects, writing images has only partial
-support via :doc:`grdimage` [3]_.
+support via :doc:`/grdimage` [3]_.
 For the full definition, see :ref:`GMT_IMAGE <struct-image>`.
 
 .. _struct-image2:
@@ -414,7 +414,7 @@ are represented by a single grid header.  Thus, all nodes along the third
 dimension are coregistered and in the horizontal plane they are, like all
 GMT grids, equidistant.  However, the spacing in the third dimension (which
 is typically depth or time) does not have to be equidistant.  At this moment,
-only :doc:`greenspline` and :doc:`grdinterpolate` can produce 3-D cubes while
+only :doc:`/greenspline` and :doc:`/grdinterpolate` can produce 3-D cubes while
 the latter can also read them (other grid modules can read individual layers
 of a cube as a single grid).
 We use the same header structure as for grids. However, some
@@ -678,7 +678,7 @@ gcc:
 
 This obviously assumes you have already installed GMT and that it is in your path.
 If you run example1 it will take a moment (this is mostly due to the gridding
-performed by :doc:`greenspline`) and then it stops.  You should find the resulting
+performed by :doc:`/greenspline`) and then it stops.  You should find the resulting
 grid junk.nc in the current directory.  Plot it to see if it makes sense, e.g.
 
 .. _example-view:
@@ -1372,7 +1372,7 @@ in which case we expect an array of strings with numbers, longitudes, latitudes,
 or ISO datetime strings and we do the conversion to internal numerical values and
 allocate a vector to hold the result in the given ``col``.  By default that vector
 will be assigned to type **GMT_DOUBLE** but you can add another primary data type
-for the conversion if you prefer (e.g., **GMT_TEXT**\|\ **GMT_LONG** to get final 
+for the conversion if you prefer (e.g., **GMT_TEXT**\|\ **GMT_LONG** to get final
 internal absolute time in integer seconds). For the special data type **GMT_TEXT** GMT
 allocates internal memory to hold the converted data and ``vector`` is not used
 any further.
@@ -1953,7 +1953,7 @@ by the specified ``mode``. There are 11 different modes available to
 programmers; for a list see Table :ref:`IO-status <tbl-iostatus>` For an example of how
 these may be used, see the test program ``testgmtio.c``. Developers who plan to import
 data on a record-by-record basis may also consult the source code of,
-say, :doc:`blockmean` or :doc:`text`, to see examples of working code.
+say, :doc:`/blockmean` or :doc:`/text`, to see examples of working code.
 
 .. _tbl-iostatus:
 
@@ -2267,7 +2267,7 @@ may be actual files of memory locations, of course.
 PostScript Access
 ~~~~~~~~~~~~~~~~~
 
-The GMT module :doc:`psconvert` is normally given one or more PostScript files that may be
+The GMT module :doc:`/psconvert` is normally given one or more PostScript files that may be
 converted to other formats.  When accessed by the API it may also be given the special
 file name "=", which means we are to use the internal PostScript string produced by
 the latest GMT plotting instead of any actual file name.  The module can access this
@@ -2850,7 +2850,7 @@ Call a module
 One of the advantages of programming with the API is that you
 have access to the high-level GMT modules. For example, if your
 program must compute the distance from a node to all other nodes in the grid
-then you can simply set up options and call :doc:`grdmath` to do it
+then you can simply set up options and call :doc:`/grdmath` to do it
 for you and accept the result back as an input grid. All the module
 interfaces are identical and are called via
 
@@ -2861,7 +2861,7 @@ interfaces are identical and are called via
     int GMT_Call_Module (void *API, const char *module, int mode, void *args);
 
 Here, ``module`` is the name of any of the GMT modules, such as
-:doc:`plot` or :doc:`grdvolume`.  All GMT modules may be called with one of
+:doc:`/plot` or :doc:`/grdvolume`.  All GMT modules may be called with one of
 three sets of ``args`` depending on ``mode``. The three modes differ in
 how the options are passed to the module:
 
@@ -3161,11 +3161,11 @@ rule says that all required input data items must be listed before any
 secondary input data items, and all primary output items must be listed
 on the left hand side before any secondary output items.
 There are three situations where the parsing will need further help;
-(1) Specifying the positions of memory arguments given to :doc:`gmtmath`,
-(2) specifying the positions of memory arguments given to :doc:`grdmath`,
+(1) Specifying the positions of memory arguments given to :doc:`/gmtmath`,
+(2) specifying the positions of memory arguments given to :doc:`/grdmath`,
 and (3) using -R? when passing a memory grid to the -R option (since just -R
 means use the previous region in the command history).
-Thus, in the :doc:`gmtmath` call we we needed to specify where
+Thus, in the :doc:`/gmtmath` call we we needed to specify where
 the specific arguments should be placed among the operators.
 API developers will rely on GMT_Open_VirtualFile_ to convert the
 above syntax to correct options for GMT_Call_Module_.
@@ -3293,7 +3293,7 @@ previously returned by GMT_FFT_Parse_. Depending on the option string you passed
 GMT_FFT_Parse_, the data may have a constant level or a trend
 removed, mirror reflected and extended by various symmetries, padded and
 tapered to desired transform dimensions, and possibly
-temporary files are written out before the transform takes place. See the :doc:`grdfft`
+temporary files are written out before the transform takes place. See the :doc:`/grdfft`
 man page for a full explanation of the options presented by GMT_FFT_Option_.
 
 Taking the FFT

doc/rst/source/debug.rst → doc/rst/source/devdocs/debug.rst

@@ -63,7 +63,7 @@ Applications).  Xcode may change as versions change; the images below is for Xco
    gmt.c itself or you need to examine the code that creates the session via a call to GMT_Create_Session
    earlier in the program.
 
-#. Now we need to specify the particular command we wish to debug.  Let's pretend that :doc:`pstext`
+#. Now we need to specify the particular command we wish to debug.  Let's pretend that :doc:`/pstext`
    crashes when we run the command::
 
     gmt pstext my_text.txt -R0/30/-10/20 -JM15c -Baf -F+f16p > text.ps

doc/rst/source/devdocs.rst → doc/rst/source/devdocs/devdocs.rst

@@ -1,6 +1,6 @@
-#######################
-Developer Documentation
-#######################
+#########################
+GMT Enhancement Proposals
+#########################
 
 This section contains low-level documentation for how some aspects of GMT have been
 implemented or are in the planning-stages for design and implementation.  Users with
@@ -12,5 +12,5 @@ notice!
    :maxdepth: 1
    :numbered:
 
-   devdocs/long_options
-   devdocs/refactoring
+   /devdocs/long_options
+   /devdocs/refactoring

doc/rst/source/postscriptlight.rst → doc/rst/source/devdocs/postscriptlight.rst

@@ -50,7 +50,7 @@ including many printers and large-format plotters. Many tools exists to
 display PostScript on a computer screen. Open source tools such as
 ghostscript can be used to convert PostScript into PDF or raster
 images (e.g., TIFF, JPEG) at a user-defined resolution (DPI). In
-particular, the GMT tool :doc:`psconvert` is a front-end to ghostscript and
+particular, the GMT tool :doc:`/psconvert` is a front-end to ghostscript and
 pre-selects the optimal options for ghostscript that will render quality
 PDF and images.
 
@@ -952,7 +952,7 @@ recreate the problem.
 See Also
 --------
 
-:doc:`psconvert`
+:doc:`/psconvert`
 
 References
 ----------

doc/rst/source/rst-cheatsheet.rst_ → doc/rst/source/devdocs/rst-cheatsheet.rst_

@@ -103,7 +103,7 @@ https://www.generic-mapping-tools.org
 Internal links
 --------------
 
-Link to the a module with :doc:`plot` or :doc:`/plot`.
+Link to the a module with :doc:`/plot` or :doc:`/plot`.
 
 Link to a section title with `Lists`_.