Proposal for Generic Mapping Tools governance structure

[maxrjones]

Here is a proposal for a governance structure for GMT, based on Pangeo's model. I have also considered the Jupyter docs (xref #6), however think a simpler approach would fit better here.

Please leave comments and suggestions on this framework via GitHub between now and May 10. We will vote on this document and any steering committee updates between May 10 and 17, 2024

[weiji14]

Thanks @maxrjones for initiating this governance doc! Looks really good overall already, but just opening the conversation on a few specific points.

[weiji14]

1. Do we agree on using the GitHub as the medium of discussion, or should we also consider the GMT forum for certain non-code-related issues?
2. Closing of an issue/PR is usually done at the discretion of a repository maintainer, though I guess we could involve the steering committee in certain situations.
3. We don't really have a blog for GMT anywhere (as far as I'm aware). Maybe state that the decision will be published somewhere on the website at https://www.generic-mapping-tools.org or on the GMT forum?

[seisman]

1. Do we agree on using the GitHub as the medium of discussion, or should we also consider the GMT forum for certain non-code-related issues?

Maybe it's better to discuss in the GitHub organization Discussions (not enabled yet).

3. We don't really have a blog for GMT anywhere (as far as I'm aware). Maybe state that the decision will be published somewhere on the website at https://www.generic-mapping-tools.org or on the GMT forum?

It's time to have a GMT blog!

[maxrjones]

Do we agree on using the GitHub as the medium of discussion, or should we also consider the GMT forum for certain non-code-related issues?
Maybe it's better to discuss in the GitHub organization Discussions (not enabled yet).

I enabled discussions on this repository. We could instead enable organization discussions, but would need to decide which repository would host the discussions. I also added that discussions could happen on the Forum.

Closing of an issue/PR is usually done at the discretion of a repository maintainer, though I guess we could involve the steering committee in certain situations.

I didn't change anything here. I'm open to removing it, but think it could be helpful to keep even if it is rarely needed.

We don't really have a blog for GMT anywhere (as far as I'm aware). Maybe state that the decision will be published somewhere on the website at generic-mapping-tools.org or on the GMT forum?

I added a note that it could be an announcement on the website. I agree that starting a blog would be nice, so I left that point.

[joa-quim]

Hi Max,

Thanks for this proposal that reads very nicely, but I'm afraid that in my view it is a bit too extended (lack a better word right now) regarding the GMT reality. For example, I would drop the _Conflict of Interest _ section all together.

Regarding the Committee role, I find it a bit lengthy and I'm not sure I understand this point:

Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests.

We certainly do not want that PRs will need the approval by the Committee to be merged.

I took a look at the GDAL Committee Guidelines and I like very much the simplicity of the “When is Vote Required?” so I made some changes to it and propose that we adopt it as

Admission of new members (under proposal of a committee member)

Granting repository commit access to new contributors (under proposal of a committee member). 

Removal of repository commit access (same procedure as for granting).

Anything that could cause backward compatibility issues.

Adding substantial amounts of new code.

When releases should take place.

Anything that might be controversial.

Note that is cover the very important and not covered point of granting commit access to new contributors.

Finally, regarding the starting Committee composition, I fully agree on having elements from MB-System and GMTSAR. Dave Caress and Eric Xu are perfect choices. The other members should be people more involved in current and past GMT development, so I propose:

• Joaquim Luis
• Remko Scharroo
• Dongdong Tian
• Federico Esteban
• Eric Xu
• Dave Caress

Of course, if any other person (namely someone from EarthScope) feel that he/she would like to make part of the committee we are open to discussion.

[maxrjones]

@weiji14, @seisman, @joa-quim thank you for the feedback.

Here are some changes based on this feedback, in addition to the in-line responses above:

For example, I would drop the _Conflict of Interest _ section all together.

I removed this section

Regarding the Committee role, I find it a bit lengthy and I'm not sure I understand this point:

Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests.

We certainly do not want that PRs will need the approval by the Committee to be merged.

I removed this bullet

I took a look at the GDAL Committee Guidelines and I like very much the simplicity of the “When is Vote Required?” so I made some changes to it and propose that we adopt it as

Admission of new members (under proposal of a committee member)

Granting repository commit access to new contributors (under proposal of a committee member).

Removal of repository commit access (same procedure as for granting).

Anything that could cause backward compatibility issues.

Adding substantial amounts of new code.

When releases should take place.

Anything that might be controversial.
Note that is cover the very important and not covered point of granting commit access to new contributors.

To me this seems similar to the point about about not wanting PRs to need approval by the Committee. I think that granting commit permissions should be at the discretion of the specific repository maintainers and not the Steering Committee. The steering committee should be providing a higher level of guidance. We could add that the Steering Committee can resolve conflicts in whether someone is granted commit access.

Finally, regarding the starting Committee composition, I fully agree on having elements from MB-System and GMTSAR.

Dave Caress and Eric Xu are perfect choices. The other members should be people more involved in current and past GMT development, so I propose:

Joaquim Luis
Remko Scharroo
Dongdong Tian
Federico Esteban
Eric Xu
Dave Caress
Of course, if any other person (namely someone from EarthScope) feel that he/she would like to make part of the committee we are open to discussion.

This is the next topic of discussion after we get this merged. I suggest we discuss separately in the Discussions section in this repository.

Can you please all give this one more review and then I will email the broader group to see if there are any objections to adopting these governance rules?

[seisman]

Looks good to me. Here a just some minor comments.

[seisman]

The PyGMT project has its own domain pygmt.org. Also add it here?

[seisman]

Perhaps we should also mention that members must have a GitHub account to participant in discussions on GitHub.

[seisman]

Given the global distribution of the Committee members, not all of them will be able to attend the meeting due to the time zones involved.

[joa-quim]

I think that granting commit permissions should be at the discretion of the specific repository maintainers and not the Steering Committee. The steering committee should be providing a higher level of guidance. We could add that the Steering Committee can resolve conflicts in whether someone is granted commit access.

I think this is the main point. For me it makes no sense to have a steering committee that is not constituted in large majority of people directly involved in the GMT development/maintenance. Sorry but "The steering committee should be providing a higher level of guidance" is something that doesn't make much sense to me and that I don't believe will ever occur. It makes me think on @WalterHFSmith stories when he described GEBCO meetings where Admirals wanted to steer the work of volunteers, which obviously didn't want to care about that steering.

For me, agreeing on the steering committee constitution is one the basic points of the governance plan. And I think that Dondong's comment about the global distribution of the Committee members also reflects that he is anticipating the committee constitution.