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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Clarify maintainers' duties #193

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Clarify maintainers' duties #193

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3c09002
Fix small typo
lcobucci Aug 12, 2024
5b27bcc
Clarify maintainers duties
lcobucci Aug 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 26 additions & 5 deletions MAINTAINERS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,18 +1,39 @@
# Laminas Project Maintainers

Maintainers are trusted contributors who have GitHub's `maintainer` rights to one or more repositories under our GitHub organizations.

Beyond driving fixes/improvements, we expect maintainers to:

- Ensure project continuity, quality, and consistency
Copy link

Choose a reason for hiding this comment

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

One thing mention in the TSC meeting was the expectation that maintainers would commit themselves to be around.

So I propose to change this requirement to:

  • Be committed to the project to ensure its continuity, quality, and consistency

- Review and merge relevant code modifications
- Triage issues
- Release new versions
- Participate in technical discussions and decision-making

We aim to have 2+ maintainers per repository.
Maintainers have GitHub maintainer rights to the repository(ies) they maintain, which means the ability to push code to the repository, manage issues and pull requests, and manipulate selected repository settings.

To become a maintainer, you must first have another maintainer or a TSC member nominate you to the TSC.
Nominations are done by submitting an issue to this repository with a title prefix of `[NOMINATION][MAINTAINER]` (or select the "Maintainer Nomination" issue type when creating an issue on this repository).
Maintainers are approved by a majority vote of the TSC, which will be held no later than 1 week following the nomination.
## Current maintainers

Current maintainers are found on the Teams page of each organization, on a team matching the repository name:

- [Laminas organization teams](https://github.com/orgs/laminas/teams)
- [Laminas API Tools organization teams](https://github.com/orgs/laminas-api-tools/teams)
- [Mezzio organization teams](https://github.com/orgs/mezzio/teams)

## Becoming a Maintainer

### Requirements

- Consistent high-quality contributions (code changes, reviews, discussions, etc) over time
Copy link
Member Author

Choose a reason for hiding this comment

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

Can we make "over time" a little more explicit?

Copy link

Choose a reason for hiding this comment

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

Who evaluates that contributions are of "high-quality"? Should it be the nominator's duty to validate that before submitting the nomination?

Copy link

Choose a reason for hiding this comment

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

It would be nice to know in advance that they will not quit after one month but you cannot expect fidelity. No one can expect fidelity of any employee in any company, so even less from volunteers in an OSS project.

However, a track record of contributions, consistent over time, would give a good warm and fuzzy feeling that the person would stick around.

I propose the following language:

  • Consistent high-quality contributions (code changes, reviews, discussions, etc) on a regular basis

- Demonstrated understanding of project goals and coding standards
Copy link
Member Author

Choose a reason for hiding this comment

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

"Demonstrate" how?

Copy link

Choose a reason for hiding this comment

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

Isn't adherence to coding standards enforced via phpcs in the CI checks?
Are the project goals defined somewhere?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not necessarily, coding standards can be related to design principles and values (which aren't always enforceable by tooling).

Would you have a better phrasing for this?

Copy link

Choose a reason for hiding this comment

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

Not really.
As a requirement, it makes sense as is. I think this is where the nominator should review the previous work of the nominee to ensure quality and adherence to standards and goals. Nominators should consult with other maintainers where the nominee's work has been reviewed, merged, etc. to get their feedback. There are not too many ways to assess the nominee's work and it would be based on judgement in the same way a supervisor would assess a subordinate's work.

- Active participation in discussions and issue resolution

Copy link

@visto9259 visto9259 Sep 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I would also add:

  • Demonstrated understanding of the contribution guidelines, such as well documented commits and pull requests, semantice versioning, etc.
  • Demonstrated understanding of the automated processes (continuous integration, automatic releases)

### Process

To become a maintainer, you must first have another maintainer or a TSC member nominate you to the TSC.
Nominations are done by submitting an issue to this repository with a title prefix of `[NOMINATION][MAINTAINER]` (or select the "Maintainer Nomination" issue type when creating an issue on this repository).
Maintainers are approved by a majority vote of the TSC, which will be held no later than 1 week following the nomination.
Copy link
Member Author

Choose a reason for hiding this comment

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

Is this 1 week following the nomination still correct?

Copy link
Member

Choose a reason for hiding this comment

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

IMO, we should change this to "the next monthly TSC meeting". An async vote, even if opened within a week would still take longer to gain the required votes, so it makes more sense to announce and start the vote at the meeting.


## Maintainers Guide

This guide is intended for *maintainers* — anybody with commit access to one or more Laminas Project repositories.
Expand Down Expand Up @@ -185,7 +206,7 @@ Examples of scenarios where notes should be added:

Releases are automatically performed by closing a milestone.
**DO NOT** close the milestone without first closing all related issues and pull requests.
The [automatic-releases workflow](https://github.com/laminas/automatic-releases) will fail in that scenario, and you will need to re-opend and re-close the milestone in order to create the release.
The [automatic-releases workflow](https://github.com/laminas/automatic-releases) will fail in that scenario, and you will need to re-open and re-close the milestone in order to create the release.

The automatic-releases workflow:

Expand Down