Skip to content
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.

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

Proposal for Generic Mapping Tools governance structure #7

Merged
merged 13 commits into from
Jun 8, 2024

Conversation

maxrjones
Copy link
Member

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

Copy link
Member

@weiji14 weiji14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

governance.md Outdated
Comment on lines 86 to 90
* New challenges for The Project will be detailed as a GitHub issue for the Community
to discuss.
* Resolved technical deadlocks will result in an explanation on the relevant
issue and/or closure of the relevant pull request.
* Other decisions will be detailed as a narrative blog post.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. 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!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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
Copy link
Member Author

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

Copy link
Member

@seisman seisman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

#### Expectations for Committee Members

Steering Committee members are expected to commit to the following activities:
- Attend a one-hour steering committee meeting every six months.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only once every 6 months. A bit of flexibility can be expected.

@joa-quim
Copy link
Member

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
Copy link
Member Author

maxrjones commented May 30, 2024

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
Copy link
Member Author

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!

Copy link

@WalterHFSmith WalterHFSmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, everyone, for good work on this.

@maxrjones maxrjones merged commit 06013c5 into main Jun 8, 2024
1 check passed
@maxrjones maxrjones deleted the add-governance-docs branch June 8, 2024 16:40
@maxrjones maxrjones mentioned this pull request Jun 17, 2024
@seisman
Copy link
Member

seisman commented Jul 2, 2024

@maxrjones Any progress on voting Steering Committee membership?

@maxrjones
Copy link
Member Author

@maxrjones Any progress on voting Steering Committee membership?

Sorry for the delay - please see #9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants