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

[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?

[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.

[maxrjones]

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.

@joa-quim could you please provide some in-line suggestions via a code review for what you'd like to see in the governance structure documentation? For example, you could add a line that states "the majority of people in the steering committee should be directly involved in the GMT [or wrappers] development/maintenance". This would be more expedient than me trying to revise based on your comments and pinging again for review. Thanks!

[maxrjones]

Alright, I think it's time to move this forward 🎉

Please approve this pull request if you are alright with this structure. I'll merge it on Sunday at 8 pm EST if there are a few approvals and no new comments. Thanks everyone!

[seisman]

@maxrjones Any progress on voting Steering Committee membership?

[maxrjones]

@maxrjones Any progress on voting Steering Committee membership?

Sorry for the delay - please see #9