fatiando / community

Community resources, guidelines, meeting notes, authorship policy, maintenance, etc.

---

Website | Documentation | Gallery | Docs (development version) | Mailing list

Disclaimer

Fatiando is under active development and we are still changing the API between releases. Names will change and functions will move as we improve our design. You might have to update your scripts and notebooks to get the latest features from a new release.

Please bear with us.

Overview

Our goal is provide a comprehensive and extensible framework for geophysical data analysis and the development of new methodologies.

Research: Make your research more reproducible by writing a Python script or Jupyter notebook instead of clicking through complicated menus.

Development: Don't start from scratch! Build upon the existing tools in Fatiando to develop new methods.

Teaching: Combine Fatiando with the Jupyter notebook to make rich, interactive documents. Great for teaching fundamental concepts of geophysics!

Getting started

1. Install Fatiando and its dependencies.
2. Browse the Gallery for examples of what Fatiando can do.
3. Take a look at the rest of the Documentation for more information about the library.
4. Get involved in the community and see how you can help in our Contributor Guide.

Contributing and asking for help

Subscribe to our Google Groups mailing list to stay informed and ask for help: groups.google.com/d/forum/fatiando

We'll post updates to the list about new releases and features, events, and future plans for the project. Get involved to help us shape the project and make it even better!

Another option for reaching out and reporting bugs is to open an issue on Github.

We have an open development process where everything is discussed through Github issues. Anyone can comment and give feedback. See our Roadmap for v1.0 to get a feeling for where the project is headed. Your input is welcome!

Supporting

If you use Fatiando in your research, please cite it in your publications as:

Uieda, L., V. C. Oliveira Jr, and V. C. F. Barbosa (2013), Modeling the Earth with Fatiando a Terra, Proceedings of the 12th Python in Science Conference, pp. 91 - 98.

Please also cite the method papers of individual functions/classes. References are available in the documentation of each module/function/class.

See the CITATION.rst file or the Citing section of the docs for more information.

You can also show your support by buying a sticker from Stickermule. We don't make any money from the sales but it helps spread the word about the project.

License

Fatiando a Terra is free software: you can redistribute it and/or modify it under the terms of the BSD 3-clause License. A copy of this license is provided in LICENSE.txt.

community's Issues

Draft Guideline to ask a question

As one of the action items at the BIRS Workshop: Open-Source Tools to Enable Geophysical Data Processing and Inversion, we worked on putting together a draft containing some important steps to orientate people about asking questions son Slack/ GitHub Forum.
Task

• Insert these guidelines as default, every time a person asks a question (Q&A)
• Create a welcome message (bot) to remind people about these steps.

---- Text-------

This is a supportive environment for asking questions, where no question is considered "stupid."
However, before asking questions, be sure to do your research. -put significant effort into finding your own solutions. Use the available resources, e.g. (previous questions on the forum, documentation, and Youtube tutorials).
Also, remember that Fatiando/Simpeg community members are professionals (professors, postdocs, students, and industry professionals) who are volunteering their time to resolve your issues. Please be patient and kind.

To ensure prompt resolution of your queries, we encourage you to adhere to the following five steps:

• Craft a concise and descriptive title

Good title: How does the order of arithmetical operations go on Python?
Bad title: [numpy] Numbers doubt

• Introduce Yourself. This is an opportunity to build your network
• Provide problem context before sharing code. Offer relevant background information and describe your issue in words. Explain how you encountered the problem and any challenges you've faced while attempting to solve it.
• Help others reproduce the problem
• Include the necessary code snippets that allow others to replicate the issue you're experiencing.
• Utilize screenshots for code, data, or error messages

Content adapted from
https://stackoverflow.com/help/how-to-ask
https://twitter.com/GeostatsGuy/status/1256975510703390726

Fatiando User Survey 2022

In our 2022-08-19 Weekly Call we decided to run a survey to gather information about our community. The goals are to help guide future project directions and gather data that can be used to support future grant applications.

This issue is to track progress of developing, rolling out the survey, and analysing the results.

Tasks:

• Start a survey in Google Forms and ask for feedback (@leouieda)
• Post a preview of the survey to this issue for further feedback (@leouieda)
• Decide on a closing date for the survey - Initially 1 month but if responses are still coming in we can keep it a bit longer.
• Publish the survey (https://forms.gle/EB4VFLY8PYb7UoJSA). Target date: 2022/09/12 (@leouieda)
• Add a top banner to the website with a link to the survey like the t-shirt one (@aguspesce )
• Write a social media message that we can share on all platforms (@MGomezN ?)
• Create a banner image to use on social media (@leouieda). Here it is: https://github.com/fatiando/logo/blob/main/banner/fatiando-survey.png

Promotion (initial 12 Sep):

• Twitter (@MGomezN)
• LinkedIn (@leouieda)
• ResearchGate (@leouieda)
• GitHub Discussions announcement as a pinned post (@santisoler)
• Software Underground post to #general (@aguspesce)
• SimPEG slack (@santisoler)
• GSH Potential Fields group (@andieie ?)
• Geolatinas (@aguspesce)
• Anywhere else?
• Please also send to personal connections that may use Fatiando.
• Post links social media on Slack/Matrix for retweets/reshares

Promotion (19 Sep):

• Twitter (@MGomezN)
• LinkedIn (@leouieda)

Promotion (3 Oct):

• Twitter (@MGomezN)
• LinkedIn (@leouieda)

Promotion (10 Oct):

• Twitter (@MGomezN)
• LinkedIn (@leouieda)
• ResearchGate (@leouieda)
• Software Underground post to #general

Social media messages

Initial post:

📣 Have you used Pooch/Verde/Harmonica/Boule/Fatiando? We need your feedback! Please fill out this survey (5-10min) https://forms.gle/EB4VFLY8PYb7UoJSA Your answers will let us know our community better and tailor development to your needs!
IMAGE: https://github.com/fatiando/logo/raw/main/banner/fatiando-survey.png
Alt: Fatiando a Terra Community Survey 2022. Fill it out today! Should only take 5-10min.

📣 Já usou Pooch/Verde/Harmonica/Boule/Fatiando? Queremos sua opinião! Por favor preencha esse formulário (5-10min) https://forms.gle/EB4VFLY8PYb7UoJSA Suas respostas nos permitirão conhecer melhor nossa comunidade e direcionar o desenvolvimento do projeto!
IMAGE: https://github.com/fatiando/logo/raw/main/banner/fatiando-survey.png
Alt: Fatiando a Terra Community Survey 2022. Fill it out today! Should only take 5-10min.

📣 Has usado Pooch/Verde/Harmonica/Boule/Fatiando? Queremos conocer tu opinión! Por favor completa este formulario (5-10min) https://forms.gle/EB4VFLY8PYb7UoJSA Tus respuestas nos permitirán conocer mejor a nuestra comunidad y mejorar el desarrollo del projecto según las necesidades de nuestres usuaries!
IMAGE: https://github.com/fatiando/logo/raw/main/banner/fatiando-survey.png
Alt: Fatiando a Terra Community Survey 2022. Complétala hoy! Solo te tomará entre 5 y 10min.

Follow up:

We need your feedback on Pooch/Verde/Harmonica/Boule/Fatiando! If you have 5-10min to spare, please fill out this survey: https://forms.gle/EB4VFLY8PYb7UoJSA
IMAGE: https://user-images.githubusercontent.com/29388479/189304150-09b6d863-89dc-44e1-aa74-e91782d76894.png

Add authorship guidelines

We should have clear guidelines for authorship in papers related to Fatiando projects. We could start with the Jupyter guidelines: https://github.com/jupyter/governance/blob/master/papers.md

I would change some of the terms to specifically mention that criteria apply between the last publication and now. So if an author in a previous publication hasn't made many contributions between then and now, they should not be included in the authors list. This is a way to make sure the project can be handed over to someone else when the current devs leave.

Change Zenodo url to Fatiando community at Zenodo

The current Zenodo link on MAINTENANCE.md points towards zenodo.org, but would be better to point to the Fatiando a Terra comunity at Zenodo and include instructions to check if the release will be linked to the community.

Generating a synthetic model

Hi, how do I generate a synthetic model? I noticed that fatiando is not recognised on python 3.

Update instructions for joining our meeting notes

Add link to the Jitsi meeting in the README.md and check the infinite loop pointing to the contact page in fatiando's website.

cc @MGomezN

Include extra independent input variables into verde_train_test_split (block) or verde_cross_val_score (block) and using polygons as inputs instead of northing/easting

Hi @leouieda,

I came across this interesting tool and wanted to use some of the functions in this package for my master thesis for handling spatial data. I would like to ask two questions:

The first question that I would like to ask is about the train_test_split with spacing and the cross validation (BlockKFold and cross_val_score) functions. I have read the documentation and source code but could not find a direct approach to the following:
How can I include extra independent or feature variables (input) into the following functions:

• verde.train_test_split(coordinates, data, weights=None, spacing=None, shape=None, **kwargs)
• verde.BlockKFold() with verde.cross_val_score(estimator, coordinates, data, weights=None, cv=None, client=None,
  delayed=False, scoring=None)

In the documentation examples I only see that the coordinates = X (two coordinate variables) and data = y (one target variable).
Would it be possible to add extra input variables (X) besides the coordinates and still having the data split into blocks?
If this would be possible, should those extra variables be added into the data argument (y) and then be splitted into X_train, y_train, X_test, y_test? or is there another approach to handle this?

The second question that I would like to ask is about the coordinates input type.
Could for example polygons be used as coordinates inputs instead of points? or is it only possible to input coordinates such as x, y or lon, lat?

The dataset that I am using has:

• around 10 numerical independent X variables
• geometry variable (polygon grid)
• centroid x, y variable from polygon grid
• 1 numerical target variable

Thank you for your advice and help.

Kind regards,

A.Azzam

Update the contact link in the documentation

Description:

Update the contact link in the documentation pages to https://www.fatiando.org/contact/. This is the new page we have that explains all the ways to reach us. It's more stable than the forward we had to our Slack channel (contact.fatiando.org). The link needs to be replaced in the doc/index.rst file of our documentation.

Apply to:

• boule
• harmonica
• pooch
• verde

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Release Drafter to help automate

Description of the desired feature

From #14:

Maintainers would be responsible for:
...
2. Making releases. Thanks to our automation, the major work here is compiling the changelog from git history and creating a Zenodo archive. A minor task is merging the PRs in the conda-forge feedstock.

I've been using Release Drafter as a GitHub Action on some projects, and found it helpful to automate compiling the changelog in GitHub releases.

It runs on merges to master, and compiles a draft release with the names of the PRs. And you can use labels to group PRs under subtitles.

An example of the two config files:

• https://github.com/hugovk/pypistats/blob/master/.github/workflows/release-drafter.yml
  config to tell GitHub when to run the action
• https://github.com/hugovk/pypistats/blob/master/.github/release-drafter.yml
  config for how the action actually runs

Then when you're ready to release, edit the draft to make changes and/or add more info as required, check the version number, and publish.

Let me know if you're interested, and I could help set it up for one repo to see how it goes, and then consider it for other repos too.

Are you willing to help implement and maintain this feature? Yes

Add another point of contact to the Code of Conduct

Right now, the only point of contact for reporting a violation of the CoC is me. This is really not ideal and it would be good to have at the very least 1 more person there (preferably 2).

Any volunteers, please let me know in the comments below.

Add instructions for new Zenodo release on existing project

When creating a new release of an existing project we want to create a new version of the already existing Zenodo release, instead of creating a new Zenodo release from scratch.

These instructions must be included inside MAINTENANCE.md.

Add link/badge to the forum

Description:

In the recent dev call we discussed making it easier to find the Fatiando forum page. We can add a link to the forum on the readme's and docs index pages for all the repositories.

We could either add text:

Ask a question!

or a badge:

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• dependente
• website
• tutorials
• community

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Create a Social Media Post Tracker

It would be good to have a check of the posts in the various networks centralized in one place in order to maximize dissemination and minimize effort.

Change the docs theme to sphinx-book-theme

We're using the Read The Docs theme, which is great but showing its age (plus, we have to do some hacking in the templates to get the edit on github button). This new theme by the JupyterBook project seems much more modern and has these buttons built in: https://sphinx-book-theme.readthedocs.io

Apply changes to

Libraries:

• boule
• harmonica
• pooch
• verde

Problem with installing on Python 3.9

I'm trying to install via pip, but everytime have this error. Can you help?

Writing C:\Users\Alexandr\AppData\Local\Temp\easy_install-2p57q5q2\fatiando-0.5\setup.cfg
Running fatiando-0.5\setup.py -q bdist_egg --dist-dir C:\Users\Alexandr\AppData\Local\Temp\easy_install-2p57q5q2\fatiando-0.5\egg-dist-tmp-lxhnyiyk
_ttime2d.c
d:\python 377\lib\site-packages\numpy\core\include\numpy\npy_1_7_deprecated_api.h(14) : Warning Msg: Using deprecated NumPy API, disable it with #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
fatiando\seismic\_ttime2d.c(2444): warning C4018: '<': signed/unsigned mismatch
fatiando\seismic\_ttime2d.c(4796): warning C4244: 'function': conversion from '__int64' to 'long', possible loss of data
fatiando\seismic\_ttime2d.c(18342): error C2039: 'exc_type': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(18343): error C2039: 'exc_value': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(18344): error C2039: 'exc_traceback': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(18345): error C2039: 'exc_type': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(18346): error C2039: 'exc_value': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(18347): error C2039: 'exc_traceback': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19000): error C2039: 'exc_type': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19001): error C2039: 'exc_value': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19002): error C2039: 'exc_traceback': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19014): error C2039: 'exc_type': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19015): error C2039: 'exc_value': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19016): error C2039: 'exc_traceback': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19017): error C2039: 'exc_type': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19018): error C2039: 'exc_value': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
fatiando\seismic\_ttime2d.c(19019): error C2039: 'exc_traceback': is not a member of '_ts'
d:\python 377\include\pystate.h(212): note: see declaration of '_ts'
error: Setup script exited with error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2

Extend support for Python 3.10

Description

Python 3.10 is due to release on October 2021 and Fatiando libraries should support it too.
There's no much work to do so, we would need to expand the automated tests on CIs to Python 3.10, add 3.10 to the setup.py and check if every test pass.

This issue was inspired on @hugovk contribution to Pooch: fatiando/pooch#260

Apply changes to

Libraries:

• boule
• harmonica
• pooch
• verde

Further instructions

In order to solve this issue we need to start opening Pull Requests on each
repository listed above. Optionally, we can open Issues on each repository if
further discussion specific to that repository is needed.

Remember to mention this Issue on every Issue or Pull Request opened on each
repository for keeping a record by adding something like:

Related to fatiando/maintenance#15

A quick checklist:

1. Open an Issue on each repository listed above (optional). Mention this Issue
   on them.
2. Open a Pull Request on the same repository to tackle the Issue. Mention this
   Issue on them.
3. Check-off the repository on the list above once the Pull Request is merged.
4. Close this issue when all items are checked-off.

We want your help

We know that maintenance tasks are very demanding, so we don't expect a single
person to tackle this issue by themselves. Any help is very welcomed, so please
comment below that you want to take care of the changes on any repository and
we will assign it to you.

Conda-forge Bot automatically creates new PRs on new release

After noticing that conda-forge has a bot that automatically creates a new PR on the conda-forge feedstock repository after a new release of the project I think we should update the instructions on MAINTENANCE.md.
As I don't have much experience with conda-forge, would you @leouieda update it?
I don't exactly know how it's working and if the bot is bullet proof or could fail on some occasions.

Expand coding guidelines in Contributing Guide

We should add guidelines based on these https://github.com/octoenergy/conventions/blob/main/conventions/python.md to our guide. We follow pretty much the same principles so it would be good adapt that guide into our own.

Thanks to @santisoler for sharing that link ❤️

Add links to Software Carpentry lessons

Description of the desired feature

Would be nice to include links to resources on how to learn Unix Shell and Version Control Git.
So, we can add the Software Carpentry lessons in the Contributing Guide.

This topic was discussed in #20

Are you willing to help implement and maintain this feature? Yes/No

Update branch protection rules in our repos

Description:

The main branch of most of our repos are protected against direct pushes by requiring that every push must be carried out through a PR. This enforces contributors, developers and maintainers to open a PR for every change, even if it's small. This ensures that the code in every commit in main is tested and passes all tests, documentation builds properly, and the change is explained and linked to a PR with a good narrative and discussion.
It also prevents that contributors with writing privileges push changes to main by mistake (we've all been there).

But, recently GitHub changed the default behaviour of the branch protection rules, making admins able to bypass all of them, pushing directly to main included. So now, even if the condition to Require a pull request before merging is checked off, admins can push directly to main.

One way to solve this is to check off a new box called Do not allow bypassing the above settings, that won't allow admins to bypass these rules.

I'm attaching a screen capture of the branch protection rules in Harmonica, highlighting the box we need to check.

I think we need to apply these changes to all our repos, mainly to prevent ourselves pushing to main by mistake.

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente
• website
• tutorials
• community
• .github

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Governance structure and community roles

We've had some discussion of this for a while now but I really want to make a push for having an official governance structure and roles within the community. It doesn't have to be complicated and can have as many or as few roles as we think we need. I'm particularly keen to get this done so that we can better recognise community members doing work that isn't captured by GitHub (like participating in discussions, managing social media, the survey, etc). I really want these to be listed and celebrated in https://www.fatiando.org/community

Proposed structure

BDFL: Benevolent Dictator For Life = me. Not much power in this, mostly a tie breaker or making hard decisions if there is no consensus. Main responsibility is thinking about the long term vision, direction, and health of the project. And not necessarily for life (I name @santisoler as an obvious successor).

Steering Council: Responsible for keeping the project running, discussing directions, recruiting volunteers for the other roles, organising events, making funding applications, etc. Would be people who are heavily involved in the project (participate in development/chat/calls/discussions). We can name some people to start and then implement a nomination and voting process for new members. This would be people like myself @santisoler @aguspesce @MGomezN @LL-Geo @mdtanker etc.

Community Managers: Responsible for breathing life into our community. Includes organising the weekly call (sending a reminder, changing time if needed, inviting specific people to attend, etc), managing social media accounts, welcoming new people to our community, approaching specific groups for engagement (Geolatinas, ESWN, and the like come mind), putting together events, running the user survey, etc. (of course, no single person needs to do all of this). This would be people like @MGomezN @santisoler @aguspesce

Package Maintainers: Responsible for a particular packages direction, development, release, and PR review. Can be more than one per package (ideally at least 2). Permission should be given rather freely since my experience has been that people respond well to being given power and responsibility. Maintainers should be in the Council but don't have to if they don't want to. This would be people like myself @santisoler at the moment (we really need to recruit a bit better on this regard). This group would need admin level permission on GitHub and PyPI to make releases. There will be one group per package, though they will likely significantly overlap.

Project Contributors: Everyone else who is involved in the project in any way. For example, people who answer questions in the forum or chat, come to the calls, submit PRs, submit issues, writes tutorials, etc. No responsibility comes with this category and we're just happy to have them involved at all. Ideally the council, community managers, and maintainers are sourced from this pool.

Package Authors: The official authors of each software package. These are people who have contributed to a package and are in the AUTHORS.md files. The idea is that people will retain this even if stepping away from other roles. The processes for being included is laid out in our Authorship Guide.

How to implement this

1. Decide on a Fatiando call if we want to do this and if this structure is acceptable.
2. Create a GOVERNANCE.md file with the above role descriptions (better worded) and other information like how to make changes to it.
3. Create GitHub teams for each role and assign the right people to each (except authors, who are sourced from the AUTHORS.md files).
4. Make sure everyone has the right permissions to do what they need, including access to other accounts like social media.
5. Add this information to the https://www.fatiando.org/community page, sourcing pictures, names, etc from the GitHub teams. This way, the teams are the only thing that need to be updated manually.

Reference

• SimPEG: https://github.com/simpeg/community/blob/main/governance.md (good model to follow since it's a similar community)
• Numpy: https://github.com/numpy/numpy/blob/main/doc/source/dev/governance/governance.rst
• Jupyter: https://github.com/jupyter/governance/blob/master/governance.md

Update Code of Conduct to v2.0

Contributor Covenant has a new version of their code of conduct. We might want to update since there are some nice changes. In particular, there is a significant extension on the Enforcement section. Please read the document and see if you agree with it.

Do people agree with this update? (👍🏽 👎🏽)

This issue will be open for comment until the next Fatiando Community Call on 2020/11/12. If there are no objections, we’ll proceed with the update.

Inspired by GenericMappingTools/pygmt#673

We should open a copy of this issue on other repositories (Verde, Harmonica, Pooch mostly) to give people who only follow those repositories a chance to comment.

Use pyproject.toml instead of setup.cfg

Description:

setuptools now allows defining all of the package data in pyproject.toml so we should do that instead of defining things in setup.cfg. The main problem is flake8 doesn't yet allow configuration in pyproject.toml so it will need a .flake8 config files of its own.

This also requires updating dependente to v0.3.0 in the GitHub Actions.

See the files in the repos that are done for a reference.

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente
• burocrata

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#143
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

about : processing and gridding gravity data with fatiando a terra

Page that contains the error or needs to be improved (paste link):
Hello, I know you are very busy, but I am asking you this question because I need your help. After watching the video on YouTube, I am processing the gravitational data with the fatiando tutorial.

1 . there are many differences between simple Bouguer and complete Bouguer , so I ask you what the problem is.

2. run Regional and Residual seperation code, the kernel continue to die.

code : deep_sources.fit((data.easting_m, data.northing_m, data.height_geometric_m), data.gravity_bouguer_mgal)

3. I want to know how to make corrections on the coast and the sea.

I'm worried if it's rude to ask.

Thank you for reading this long article.

I'll attach the file together

thanks
Description of the problem/suggestion:

gebco_harmonica_sandwell.ipynb.zip

Add automated test for checking license notice on every source file

Description

Since fatiando/maintenance#10 we want that every source file (.py file) to have a license and copyright notice at the top.
Although adding the notice to every file is very straight forward through some scripting, I can definitely see myself forgetting to add the notice to any new file I add to any library.

Would be nice to have an automated test on CIs that checks if every .py file has the copyright notice.
Also would be very nice to add a new task on the format target: to run the script that adds the license notice to every .py file that doesn't have it.

Apply changes to

Libraries:

• boule
• harmonica
• pooch
• verde

Further instructions

In order to solve this issue we need to start opening Pull Requests on each
repository listed above. Optionally, we can open Issues on each repository if
further discussion specific to that repository is needed.

Remember to mention this Issue on every Issue or Pull Request opened on each
repository for keeping a record by adding something like:

Related to fatiando/maintenance#12

A quick checklist:

1. Open an Issue on each repository listed above (optional). Mention this Issue
   on them.
2. Open a Pull Request on the same repository to tackle the Issue. Mention this
   Issue on them.
3. Check-off the repository on the list above once the Pull Request is merged.
4. Close this issue when all items are checked-off.

We want your help

We know that maintenance tasks are very demanding, so we don't expect a single
person to tackle this issue by themselves. Any help is very welcomed, so please
comment below that you want to take care of the changes on any repository and
we will assign it to you.

Use Trusted Publishers in PyPI instead of API tokens

Description:

To get GitHub actions publishing to PyPI and TestPyPI, we had to create API tokens for each project and add them as Secrets to the respective repositories. These tokens are a bit dangerous if they leak since they give publishing rights. A better approach is the new Trusted Publishers in PyPI. Basically, admins can configure PyPI to exchange tokens with an Action running on a particular repo. Then we don't need the API tokens.

To do this:

1. Make sure the PyPI Action is at least v1.8.12.
2. On PyPI and TestPyPI, go to the package configuration, then "Publishing" and add our repository as a trusted publisher. Set the "environment" to "pypi".
3. On the repository, edit the publish job of pypi.yml to look like this:

 publish:
    runs-on: ubuntu-latest
    needs: build
    # Only publish from the origin repository, not forks
    if: github.repository_owner == 'fatiando' && github.event_name != 'pull_request'
    environment: pypi
    permissions:
      # This permission allows trusted publishing to PyPI (without an API token)
      id-token: write

4. Remove the following from the steps that use the PyPI Action:

with:
  user: __token__
  password: ${{ secrets.TEST_PYPI_TOKEN}}

5. Delete the PYPI_TOKEN and TEST_PYPI_TOKEN from the Secrets tab in the repository
6. Remove the token from PyPI and TestPyPI

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente
• burocrata

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Update Contributing guidelines after nox is implemented on every package

Description of the desired feature

After the implementation of nox on every Fatiando package, we should update the contributing guidelines.

Related to fatiando/maintenance#8

Are you willing to help implement and maintain this feature? Yes

Start a document explaining who administers/owns Fatiando accounts

We have several accounts on different sites that are related to Fatiando. We need to create a list of who is an owner/administrator on each so we have a sense of what is going on and where we should add new maintainers. This would be good as a section of the README of this repository or a separate file.

Off the top of my head:

• Twitter
• fatiando.org domain (from Hover)
• GitHub organisation
• PyPI packages
• TestPyPI packages
• YouTube (Google brand account)

Extend support for Python 3.9

Description

Being Python 3.9 the latest major release, Fatiando libraries should support it too.
There's no much work to do so, we would need to expand the automated tests on CIs to Python 3.9, add 3.9 to the setup.py and check if every test pass.

Apply changes to

Libraries:

• boule
• harmonica
• pooch
• verde

Further instructions

In order to solve this issue we need to start opening Pull Requests on each
repository listed above. Optionally, we can open Issues on each repository if
further discussion specific to that repository is needed.

Remember to mention this Issue on every Issue or Pull Request opened on each
repository for keeping a record by adding something like:

Related to fatiando/maintenance#14

A quick checklist:

1. Open an Issue on each repository listed above (optional). Mention this Issue
   on them.
2. Open a Pull Request on the same repository to tackle the Issue. Mention this
   Issue on them.
3. Check-off the repository on the list above once the Pull Request is merged.
4. Close this issue when all items are checked-off.

We want your help

We know that maintenance tasks are very demanding, so we don't expect a single
person to tackle this issue by themselves. Any help is very welcomed, so please
comment below that you want to take care of the changes on any repository and
we will assign it to you.

Add community calls 2022

Download and add to this repo https://hackmd.io/@fatiando/development-calls-2022

Format docstrings with 80 chars

As pointed out by @prisae earlier, our docstrings are following the Black standard line length but tools like Jupyter format everything at 80 chars. So our docstrings are kind of unreadable in Jupyter and IPython. We really need to reformat docstrings to 80 chars again. To this point, we'll need a lot of PRs to all our projects that reformats the docstrings manually (since black won't do it). We should also have a PR on this repo adding this requirement to our CONTRIBUTING.md (it will get propagated to our other repos by the bot).

Replace license checking script with Burocrata

Description:

Burocrata is a CLI tool that does what that script did. We can now replace it in all our repositories. Doing this means adding Burocrata to the development environment and adding the license notice text to pyproject.toml.

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Make sure "main" branches are protected

Description:

As a general safety measure, it would be good the main branches of all repositories were protected from force pushes or pushes of any kind really. This way changes have to go through PRs and it's harder to accidentally push to main instead.

Most repos should already have something like this in place but it would be good to double check and make sure it's standard in all our repos.

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• dependente
• website
• tutorials
• community: Can't because HackMD needs to push the call notes.
• .github

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Stop distributing test files?

Description:

Currently most of our libraries hold their test functions along with the source code. Moreover, when we distribute the code (upload to PyPI or conda-forge) we are also providing this test functions and classes, along with the test data they need. This forces each user to download a bunch of files that they are not going to ever use (see #44). Particularly Harmonica is seeing its test/data folder to growing a lot with sample grid files.

Would be better if we don't distribute the test folder inside the source code of our packages. This will lower the bandwidth and disk space required to install our packages without changing the user experience. If anyone wants to test the code, they will have to git clone the repo and run the tests, but this is how they should do so already.

Is there any reason why we would like to keep distributing those?

cc @leouieda

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#77
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Migrate the CI here to Github Actions

The CI for this repository using TravisCI and hub to open pull requests on the project repositories with any changes. This would be a good place to start replacing Travis with Github Actions. The script that does everything is in ci and would likely need updating. If there is a better way to do this that doesn't involve hub that would be great.

Related to fatiando/maintenance#1

Ditch Google Analytics and use Plausible

Description:

On the Development Call of 2022-01-14 we decided to stop using Google Analytics and replace it for Plausible, an open-source lightweight and privacy-friendly alternative.

We should replace the existing Google Analytics script:

  <!-- Google Analytics tracking code -->
  <script>
    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
        (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new
          Date();a=s.createElement(o),
          m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
      })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

    ga('create', 'UA-38125837-1', 'auto', {'storage': 'none'});
    ga('set', 'anonymizeIp', true);
    ga('send', 'pageview');
  </script>

For this one:

  <!-- Plausible analytics for anonymous usage statistics -->
  <script defer data-domain="fatiando.org" src="https://plausible.io/js/plausible.js"></script>

This should be done through out the websites of the project, including:

• Main website
• Documentation for each library (on main branch, so we will start using it after we build and deploy)
• Older documentations for each library (this should be done manually -or with a script- directly into the gh-pages branches)
• Legacy website (it should also be done manually)

Apply to:

Here I list all the repos that should be modified. For each one of the packages repos, check the box only after the snippet has been replaced in the main branch and in the older docs as well.

• boule
• harmonica
• pooch
• verde
• ensaio
• website
• legacy-docs

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Update

Considering the documentation pages of the older versions of each package we can count +200 HTML files that need to be modified. So it's better to perform this change automatically.

I wrote a simple Python script to apply the modifications to a single HTML file:

plausible.py:

#!/usr/bin/env python
"""
Replace Google Analytics snippet for the one for Plausible
"""

import sys

domain = "fatiando.org"
plausible_lines = [
    "<!-- Plausible analytics for anonymous usage statistics -->\n",
    f'<script defer data-domain="{domain}" src="https://plausible.io/js/plausible.js"></script>\n',
]

# Get filename from the first argument
filename = sys.argv[1]

# Read html file
content = []
in_script = False
with open(filename, "r") as f:
    for line in f:
        if "Google Analytics" in line:
            in_script = True
            # Get number of indentation spaces
            n_spaces = 0
            for n_spaces, char in enumerate(line):
                if char != " ":
                    break
                n_spaces += 1
            # Append the plausible lines to the content list
            for plausible in plausible_lines:
                content.append(" " * n_spaces + plausible)
        if in_script and "</script>" in line:
            in_script = False
            continue
        if not in_script:
            content.append(line)

# Overwrite file
with open(filename, "w") as f:
    f.write("".join(content))

To use it, copy and paste the code to a file, give it execution permissions with chmod u+x plausible.py and run it by passing the html file that you want to change as the first argument:

./plausible.py index.html

In order to run this script over multiple files, we can use the following bash line:

for file in **/*.html; do ./plausible.py $file; done

Check if the changes have been successfully applied by running git diff.

We can change the domain from fatiando.org to something like legacy.fatiando.org by changing the domain variable in the plausible.py script.

Deprecate the "test" functions in our packages

Description:

All our packages include a test function in their base __init__.py that was used as a way to test the version of the package that has actually been installed. But now they are not needed and hardly ever used since the same functionality can be achieved with pytest --pyargs PACKAGE_NAME.

We should deprecate these functions by including a FutureWarning when they are called. The functions would then be removed in the next major release or after 2 minor releases for packages pre-1.0.

See fatiando/verde#344 for a template.

Apply to:

• boule
• harmonica
• pooch
• verde

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Dependency version support plan

Description:

We currently don't really specify the supported versions of many of our dependencies. We've been fine so far but some things are beginning to break, for example the Verde CI has been breaking in Python 3.6 (fatiando/verde#333). I think it's time we adopted a formal policy for dropping older versions of dependencies and implemented testing mechanisms to make sure things work as intended.

Proposal:

I propose we follow NEP 29:

• Support the versions of Python released in the past 42 months (at least 2 minor versions)
• Support the versions of Numpy released in the past 24 months (at least 3 minor versions)

And extend it with:

• Apply the Numpy policy (24 months / 3 versions) to our other run-time dependencies (not development or documentation dependencies)
• Older versions can still be maintained as long as the CI tests still pass and it doesn't cause extra work for us. In other words, we drop them when they become a hindrance.

Implementation:

All projects will need to:

• Add the policy and expected support time frame to the documentation.
• Add minimum version numbers to their run-time dependencies (usually in requirements.txt but also in the conda-forge recipe).
• Add CI jobs that run tests on the minimum supported version of all packages. This can be a single job for each platform Linux/Mac/Windows. The specification can be done by replacing the >= in the requirements file with a == using sed.

Exceptions:

The only exception I can think of is Pooch, which is used by other libraries and should endeavour to support the minimum Python versions supported by these libraries. We should also be more conservative the number of versions supported of dependencies since we don't want to be the cause of broken environments.

Apply to:

• boule
• harmonica
• pooch
• verde

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Fatiando installation

I want to install fatiando, but i did not know what python i have to install (2 or 3). Can any one advise me.

Replace the author email with the Fatiando account

Description:

The PyPI metadata in all packages asks for an email for the package maintainer or author. Not sure if this is required but we now have a Fatiando protonmail account [email protected]

We should replace my email in all setup.py files across the organisation.

Apply to:

• boule
• harmonica
• pooch
• verde

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Formalize mission statement and values

In 2022-11-09 Meeting notes We decided the first mission of the council is to formalize our mission statement and values in a document MISSION_VALUES.md

• Mission statement
• Values
• Why do what we do?
• Include document on main in community

Useful references to build this document

• FAIR guiding principles for Research Software (FAIR4RS) and for scientific data
• Post-meritocracy manifesto
• Reference useful for @MGomezN:

"Most people define themselves by what they do - trade stocks, study Byzantine art or fight for human rights worldwide. But these are simply the tangible examples of something deeper — a single passion that unites these interests or activities. We inherently know WHAT we do is not enough, so in an attempt to distinguish ourselves, we explain HOW we do WHAT we do (...) starting with WHAT or HOW, does not, in reality, distinguish us (...) Being able to clearly state our WHY allows us to explain the reasons we choose to do the things we do. When we know our WHY, we can choose to do and say the things that reflect what we believe (...) the combination becomes like our fingerprint. It is our identity, now and forever. " Stand Out in the Job Market by Simon Sinek

Official Fatiando Mastodon account?

Well, since it actually happened and a lot of people are leaving twitter should we create a Fatiando Mastodon account? Like with LinkedIn, we would mostly post the same things on all our social media so it's not that much more work.

Possible server is: https://fosstodon.org/about/more Only problem is that they only allow toots in English because of moderation. We don't really post much in other languages so maybe it's not a big issue. Or it is and we can look for another server (suggestions welcome).

cc @santisoler @MGomezN @aguspesce

Automatically update files on projects after new commit on contributing repo

The files inside this repo are maintained here, but they are useful on each projects inside the Fatiando ecosystem. That's where they are ultimately read and has meaning and purpose.
Would be nice to automate the update process of those files -- when a commit is pushed on contributing, the changes would be automatically applied to each project.

Two methods come to my mind:

1. Use git submodule on the projects' repositories to have the latest version of contribute inside them.
2. Use Travis CI to open PRs on each project committing the changes on contribute:master.

I don't quite like the first idea, because the submodule has to be manually updated and we cannot link single files (we would need to create symlinks to the submoduled files -- see this).

The second approach is way better: the updates should be done manually, but only by merging a few PRs. Although I don't know if Travis CI is capable of opening new PRs on a different repository.
Maybe we will need to access the GitHub API with tools such as pyGitgub or hub.

What do you think @leouieda?

More specific instructions in the Contributing Guide for each task type

In fatiando/.github#11, @MGomezN pointed out that we list contribution types at the start of the guide but then don't really provide specific instructions for each of these categories. The guide should be updated so that the instructions below match (and are linked from) the different contribution categories.

From that PR:

But, when breaking down the information, it is not very clear specific instructions for 📝 "Writing tutorials or examples". I was reading the instructions for "💡 Writing code for everyone to use" and that's why I was trying to install Make, rather than for the reminder itself.

This would make it easier for us to create a reminder list for PRs in code related repos that is better linked to the contributing guide.

Add files listing package maintainers

Description:

After being discussed in the Fatiando Call of 2024-01-18, we noticed that we don't have a public list of the maintainers for each package.

To tackle this, we decided to add a MAINTAINERS.md file on each repo listing them. Its format could be similar to the ones for AUTHORS.md, although I don't think we need to add affiliation or DOI.

Something like this could work:

# Project maintainers

- [First Last Name](https://github.com/github-handle)

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#137
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Move changelogs to `CHANGELOG.md` in the root of repos?

Description:

This week I came across with https://keepachangelog.com/, a nice project that sets guidelines for writing changelogs in a simple way. I was happy to see that we are already following most of their guidelines (dividing in categories, linking the items to PRs, adding the release date to each version, latest goes first, etc).

Although there are some neat ideas that we are not strictly following. I think the main one is keeping the changelog in a Markdown file called CHANGELOG.md in the root of the repository. Instead, we keep in a changes.rst file inside the doc folder. I think the name is not the best one (changelog > changes), and keeping it hidden in the doc folder makes it harder to discover it.

Moreover, in our Release checklist we instruct maintainers to create a Markdown version of the changelog to be pasted in the GitHub Release notes. So we are already generating the changelog in Markdown at some point in the release process.

So, my proposal would be to:

1. Move the doc/changes.rst files in our repos to a CHANGELOG.md file in the root of the repositories. Sphinx will have to load that file to create the changelog in the website.
2. Update the release checklist:
   • Instruct to copy the latest changes to CHANGELOG.md (in Markdown)
   • Update the bash command to create links to PRs (it should create Markdown links instead of rst links)
   • Remove the "generate a Markdown version of the latest changes"

Apply to:

• boule
• harmonica
• pooch
• verde
• ensaio
• choclo
• dependente

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#105
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

Rename this repository to "community"

In the December 2020 community call, we decided that this repository would be better named community instead since it hosts community files, like the CoC and authorship policy. We also plan on hosting the new discussion boards here for all projects.

The rename should be safe since GitHub redirects uses of the old name. That said, we need to change the links in:

• This repository: README, documents, CI scripts
• The website

Maintainers for packages

Right now, the maintenance roles across our packages are a bit fuzzy. I do a lot of the releasing and admin and @santisoler has been stepping up quite a bit in Harmonica and RockHound. It would be nice to have explicitly defined maintainers for each project (in a document here maybe and also in each project's README).

Maintainers would be responsible for:

1. Merging PRs (usually also reviewing but others are welcome take on the responsibility).
2. Making releases. Thanks to our automation, the major work here is compiling the changelog from git history and creating a Zenodo archive. A minor task is merging the PRs in the conda-forge feedstock.
3. Welcoming and recruiting new contributors to each project. This includes mentoring those who wish to contribute something. Of course, this is a shared responsibility but maintainers would be expected to be a role model.

Of course, this is just off the top of my head and open to debate and change.

To their jobs, maintainers would be granted administrator rights to:

1. The repository they maintain (meaning they will be added to the corresponding Github team)
2. PyPI (which is usually never really used since we deploy automatically)
3. CIs (to be able to start and stop jobs, edit configuration, secret variables, etc)
4. conda-forge (by being listed as a maintainer in the recipe)

Ideally, we should have at least 2 maintainers for each package to increase our bus factor.

To be a maintainer of a projects, it seems reasonable to require being active in the project and somewhat knowledgeable of the code base.

Maintainer roles can be changed at any time to accommodate personal/professional life and should not be seen as a permanent commitment.

What I would like to know from the community:

1. Are these reasonable responsibilities/expectations/requirements?
2. What could/should be changed to help preserve the well-being of maintainers?
3. Does anyone wish to volunteer?

Currently, me and @santisoler are maintainers for all packages. It would be great to add more people to share the burden.

Create fatiando metapackage

Description

Would be nice to publish a fatiando metapackage to PyPI and conda-forge so any user can install the latest release of all Fatiando a Terra libraries on a single line, as we used to install the old fatiando package:

pip install fatiando

conda install -c conda-forge fatiando

When doing so we should update the docs of fatiando v0.5 so anyone interested using the old package can still use it.

Fatiando Community Calls

Hi @fatiando/contributors, I'm thinking of starting bi-weekly Fatiando Community Calls next month. How about we kick this off Friday 15 of May at 15:00 UTC?

These calls are open to anyone interested in getting involved. We would discuss developments in the various projects and just have a quick chat to get to know each other better. Ideally, I would want to keep the calls to ~40 min.

Let me know if you'd like to attend. If you want to participate but the time doesn't work for you, let me know as well.

I made a calendar for the project here to make it easier to track events: http://calendar.fatiando.org

The meeting notes will be here: https://hackmd.io/@fatiando/community-calls-2020