- Add scheduled approval for trusted stale lead maintainer PRs
- Move approval checks into a `utils/github` Ruby script
- Short-circuit API reads once approval is impossible
- Require stale PRs to be open 48 hours without review
- Permit recent approval evidence from fork PRs
- Refuse to auto-approve sensitive paths
- Use event type for branch push reports
- Document the supply-chain guardrails and maintainer behaviour
- explain the principles behind our AI/LLM usage rules for
maintainers and contributors rather than just the requirements
- riff off Administrate's "AI at Administrate" guidance: human in
the loop, trust appropriately, use AI to improve AI, try things
- cross-link from the index, `CONTRIBUTING` guide, pull request
template, PR how-to, maintainer guidelines and new maintainer
checklist so the guidance is discoverable where AI use comes up
- add a dedicated guide for upstream projects working with Homebrew
- link relevant maintainer and policy docs to the new guidance
- explain escalation and decision-making expectations more clearly
- Most of these were fine still, apart from:
- FAQ: `hub` is less maintained than `gh`.
- Brew-Maintainer-Guide: link to GitHub docs on commit signing via GPG or SSH.
- Interesting-Taps-and-Forks: remove outdated information about `homebrew/core` being in `Library/Taps`.
- New-Maintainer-Checklist: remove outdated information about the `@members` team.
- At the AGM we formed an ad-hoc documentation working group.
- One of our ideas was that we should have a last reviewed date for
documentation, so that we can periodically implement a review
mechanism (GitHub Actions posts to Slack for a regular documentation
outdatedness check?) to track how old docs are and ensure they're
still relevant.
- This is a first step towards that goal, by adding a `last_review_date`
to the metadata of all docs with a date of earlier than Homebrew's
inception because everything needs reviewing so that we start from a
good base!
- Move the guidelines from Homebrew/brew Maintainer Guide to
Maintainer Guidelines as they apply to all repositories.
- Clarify the guidelines to make it clear that the default option
should be to approve a PR, with or without comments.
- Note in the New Maintainer Checklist that the most important task for
maintainers is reviewing pull requests.
Co-authored-by: Issy Long <me@issyl0.co.uk>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
Co-authored-by: Eric Knibbe <enk3@outlook.com>
Adjust various maintainer and contributor-focused documents after
recent maintainer conversations and generally anything I noticed was
wrong or outdated as I went through these.
- Add flowchart for handling ready-to-merge pull requests
- Add diagram guidelines
Many thanks to Sean Molenaar for the idea and initial version of the
chart.
CC: Sean Molenaar <smillernl@me.com>
Anywhere we can use `blob/master` we can use `blob/HEAD` instead. This
will make life easier if we ever rename our default branch in future
(once/if Git and GitHub provides the necessary tooling to do so).
- Thanks to #7709, we've saved some maintainer time from doing this
manually.
- To check that it's working, search for "Mirrored <formula_name>" in the CI
log output for the publish bottles action for relevant formulae like
ImageMagick in the future.
- I vaguely remembered that ImageMagick was a download we mirrored on
BinTray and that doing so required some manual effort post-merge. I
went looking for some docs to confirm that memory, but didn't find
any.
- Fix Markdown format
- Note Linux in the mission statement
- Update the maintainer guidelines based on current state
- Loosen the new maintainer expectations
- Clarify what things the PLC should be added to
- Add documentation for making a new Homebrew release
Today the Homebrew maintainers elected a new PLC, TSC and project lead.
Documentation is to follow detailing exactly the responsibilities for
each of these roles but adjust these to reflect the current state until
that point.
I'll step down on February 4th to better coincide with the Homebrew
maintainers in-person conference. This will make it easier to resolve
any logistical issues that arise.
Mike McQuaid