Skip to content

Specify header sizes in style.css and remove bold formatting from contributing.md headers #1385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
maxrjones merged 2 commits into from
Jul 16, 2021
Merged

Specify header sizes in style.css and remove bold formatting from contributing.md headers #1385

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b1478cf
Specify header sizes in style.css
Jul 15, 2021
1fbb906
Increase difference between h2 and h3 header size
Jul 16, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions doc/_static/style.css
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,23 @@ h1, h2, h3, h4 {
font-family: "Atkinson Hyperlegible", sans-serif;
}

/* Set the header font sizes */
h1 {
font-size: 200%;
}

h2 {
font-size: 185%;
}

h3 {
font-size: 150%;
}

h4 {
font-size: 130%;
}

p {
font-size: 1.05em;
}
Expand Down
64 changes: 32 additions & 32 deletions doc/contributing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,9 @@ The goal is to maintain a diverse community that's pleasant for everyone.
[Code of Conduct](https://github.com/GenericMappingTools/pygmt/blob/master/CODE_OF_CONDUCT.md)
and we encourage all to read it carefully.

## **Ways to Contribute**
## Ways to Contribute

### **Ways to Contribute Documentation and/or Code**
### Ways to Contribute Documentation and/or Code

* Tackle any issue that you wish! Some issues are labeled as **"good first issues"** to
indicate that they are beginner friendly, meaning that they don't require extensive
Expand All @@ -22,7 +22,7 @@ and we encourage all to read it carefully.
* Contribute code! This can be code that you already have and it doesn't need to be
perfect! We will help you clean things up, test it, etc.

### **Ways to Contribute Feedback**
### Ways to Contribute Feedback

* Provide feedback about how we can improve the project or about your particular use
case. Open an [issue](https://github.com/GenericMappingTools/pygmt/issues) with
Expand All @@ -31,17 +31,17 @@ and we encourage all to read it carefully.
* Help triage issues, or give a "thumbs up" on issues that others reported which are
relevant to you.

### **Ways to Contribute to Community Building**
### Ways to Contribute to Community Building

* Participate and answer questions on the [PyGMT forum Q&A](https://forum.generic-mapping-tools.org/c/questions/pygmt-q-a/11).
* Participate in discussions at the quarterly PyGMT Community Meetings, which are
announced on the [forum governance page](https://forum.generic-mapping-tools.org/c/governance/9).
* Cite PyGMT when using the project.
* Spread the word about PyGMT or star the project!

## **Providing Feedback**
## Providing Feedback

### **Reporting a Bug**
### Reporting a Bug

* Find the [*Issues*](https://github.com/GenericMappingTools/pygmt/issues) tab on the
top of the GitHub repository and click *New Issue*.
Expand All @@ -50,7 +50,7 @@ top of the GitHub repository and click *New Issue*.
* After submitting your bug report, try to answer any follow up questions about the bug
as best as you can.

### **Submitting a Feature Request**
### Submitting a Feature Request

* Find the [*Issues*](https://github.com/GenericMappingTools/pygmt/issues) tab on the
top of the GitHub repository and click *New Issue*.
Expand All @@ -59,7 +59,7 @@ top of the GitHub repository and click *New Issue*.
* After submitting your feature request, try to answer any follow up questions as best
as you can.

### **Submitting General Comments/Questions**
### Submitting General Comments/Questions

There are several pages on the [Community Forum](https://forum.generic-mapping-tools.org/)
where you can submit general comments and/or questions:
Expand All @@ -71,9 +71,9 @@ where you can submit general comments and/or questions:
* To share your work, select *New Topic* from the
[Showcase Page](https://forum.generic-mapping-tools.org/c/Sow-your-nice-example-script/10).

## **General Guidelines**
## General Guidelines

### **Resources for New Contributors**
### Resources for New Contributors

Please take a look at these resources to learn about Git and pull requests (don't
hesitate to [ask questions](#getting-help)):
Expand All @@ -82,13 +82,13 @@ hesitate to [ask questions](#getting-help)):
* [Git Workflow Tutorial](http://www.asmeurer.com/git-workflow/) by Aaron Meurer.
* [How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github).

### **Getting Help**
### Getting Help

Discussion often happens on GitHub issues and pull requests. In addition, there is a
[Discourse forum](https://forum.generic-mapping-tools.org/c/questions/pygmt-q-a) for
the project where you can ask questions.

### **Pull Request Workflow**
### Pull Request Workflow

We follow the [git pull request workflow](http://www.asmeurer.com/git-workflow)
to make changes to our codebase. Every change made goes through a pull request, even
Expand All @@ -97,7 +97,7 @@ our own, so that our
services have a chance to check that the code is up to standards and passes all
our tests. This way, the *master* branch is always stable.

#### **General Guidelines for Making a Pull Request (PR):**
#### General Guidelines for Making a Pull Request (PR):

* What should be included in a PR
- Have a quick look at the titles of all the existing issues first. If there
Expand Down Expand Up @@ -127,7 +127,7 @@ our tests. This way, the *master* branch is always stable.
- Be aware that the pull request review process is not immediate, and is
generally proportional to the size of the pull request.

#### **General Process for Pull Request Review:**
#### General Process for Pull Request Review:

After you've submitted a pull request, you should expect to hear at least a
comment within a couple of days. We may suggest some changes, improvements or
Expand Down Expand Up @@ -157,7 +157,7 @@ Try to get them all passing (green).
If you have any trouble, leave a comment in the PR or
[get in touch](#how-can-i-talk-to-you).

## **Setting up your Environment**
## Setting up your Environment

These steps for setting up your environment are necessary for
[editing the documentation locally](#editing-the-documentation-locally) and
Expand Down Expand Up @@ -203,9 +203,9 @@ This installs your project in *editable* mode, meaning that changes made to the
code will be available when you import the package (even if you're on a different
directory).

## **Contributing Documentation**
## Contributing Documentation

### **PyGMT Documentation Overview**
### PyGMT Documentation Overview

There are four main components to PyGMT's documentation:

Expand Down Expand Up @@ -235,7 +235,7 @@ There are two primary ways to edit the PyGMT documentation:
In order to build the documentation locally, you first need to
[set up your environment](#setting-up-your-environment).

### **Editing the Documentation on GitHub**
### Editing the Documentation on GitHub

If you're browsing the documentation and notice a typo or something that could be
improved, please consider letting us know by [creating an issue](#reporting-a-bug) or
Expand Down Expand Up @@ -268,7 +268,7 @@ Alternatively, you can make the changes offline to the files in the `doc` folder
example scripts. See [editing the documentation locally](#editing-the-documentation-locally)
for instructions.

### **Editing the Documentation Locally**
### Editing the Documentation Locally

For more extensive changes, you can edit the documentation in your cloned repository
and build the documentation to preview changes before submitting a pull request. First,
Expand All @@ -284,7 +284,7 @@ This will build the HTML files in `doc/_build/html`.
Open `doc/_build/html/index.html` in your browser to view the pages. Follow the
[pull request workflow](#pull-request-workflow) to submit your changes for review.

### **Contributing Gallery Plots**
### Contributing Gallery Plots

The gallery and tutorials are managed by
[sphinx-gallery](https://sphinx-gallery.readthedocs.io/).
Expand Down Expand Up @@ -315,7 +315,7 @@ General guidelines for making a good gallery plot:
documentation.
* SI units should be used in the example code for gallery plots.

### **Contributing Tutorials**
### Contributing Tutorials

The tutorials (the User Guide in the docs) are also built by sphinx-gallery from the
`.py` files in the `examples/tutorials` folder of the repository. To add a new tutorial:
Expand Down Expand Up @@ -343,7 +343,7 @@ Guidelines for a good tutorial:
Note that the `Figure.show()` function needs to be called for a plot to be inserted into
the documentation.

### **Editing the API Documentation**
### Editing the API Documentation

The API documentation is built from the docstrings in the Python `*.py` files under
the `pygmt/src/` and `/pygmt/datasets/` folders. **All docstrings** should follow the
Expand All @@ -355,7 +355,7 @@ While the maximum line length for code is automatically set by Black, docstrings
must be formatted manually. To play nicely with Jupyter and IPython, **keep docstrings
limited to 79 characters** per line.

### **Standards for Example Code**
### Standards for Example Code

When editing documentation, use the following standards to demonstrate the example code:

Expand All @@ -373,7 +373,7 @@ When editing documentation, use the following standards to demonstrate the examp
with [ ] (square brackers) with the prefix "Default is". Example: [Default is
**p**].

### **Cross-referencing with Sphinx**
### Cross-referencing with Sphinx

The API reference is manually assembled in `doc/api/index.rst`.
The *autodoc* sphinx extension will automatically create pages for each
Expand Down Expand Up @@ -410,15 +410,15 @@ For GMT configuration parameters, an example is
Sphinx will create a link to the automatically generated page for that
function/class/module.

## **Contributing Code**
## Contributing Code

### **PyGMT Code Overview**
### PyGMT Code Overview

The source code for PyGMT is located in the `pygmt/` directory. When contributing
code, be sure to follow the general guidelines in the
[pull request workflow](#pull-request-workflow) section.

### **Code Style**
### Code Style

We use some tools to to format the code so we don't have to think about it:

Expand Down Expand Up @@ -459,7 +459,7 @@ make check # Runs black, blackdoc, docformatter, flake8 and isort (in check mo
make lint # Runs pylint, which is a bit slower
```

### **Testing your Code**
### Testing your Code

Automated testing helps ensure that our code is as free of bugs as it can be.
It also lets us know immediately if a change we make breaks any other part of the code.
Expand Down Expand Up @@ -503,15 +503,15 @@ or run tests which contain names that match a specific keyword expression:

pytest -k KEYWORD pygmt/tests

### **Testing Plots**
### Testing Plots

Writing an image-based test is only slightly more difficult than a simple test.
The main consideration is that you must specify the "baseline" or reference
image, and compare it with a "generated" or test image. This is handled using
the *decorator* functions `@pytest.mark.mpl_image_compare` and `@check_figures_equal`
whose usage are further described below.

#### **Using mpl_image_compare**
#### Using mpl_image_compare

> **This is the preferred way to test plots whenever possible.**

Expand Down Expand Up @@ -553,7 +553,7 @@ Don't forget to commit the baseline image as well!
The images should be pushed up into a remote repository using `dvc` (instead of
`git`) as will be explained in the next section.

#### **Using Data Version Control ([dvc](https://dvc.org)) to Manage Test Images**
#### Using Data Version Control ([dvc](https://dvc.org)) to Manage Test Images

As the baseline images are quite large blob files that can change often (e.g.
with new GMT versions), it is not ideal to store them in `git` (which is meant
Expand Down Expand Up @@ -620,7 +620,7 @@ summarized as follows:
git push
dvc push

#### **Using check_figures_equal**
#### Using check_figures_equal

This approach draws the same figure using two different methods (the reference
method and the tested method), and checks that both of them are the same.
Expand Down