Meta tags:
description=Documentation for the missing package manager for macOS (or Linux).;

Headings (most frequently used words):

prs, homebrew, documentation, maintainer, guidelines, overview, reviewing, mission, common, gotchas, reverting, communication, add, comments, don, allow, bloated, diffs, closing, issues, give, time, for, other, maintainers, to, review,

Text of the page (most frequently used words):
the (57), and (37), maintainers (28), #maintainer (28), homebrew (26), you (23), that (20), should (19), for (19), this (19), are (18), not (17), with (16), can (16), issue (15), they (14), have (14), prs (13), #comments (13), changes (13), other (11), merged (11), before (11), review (11), when (10), approve (10), any (9), merge (9), github (8), make (7), them (7), possible (7), but (7), than (7), use (7), project (6), communication (6), more (6), another (6), core (6), fix (6), until (6), approval (6), reviewing (6), team (6), may (5), all (5), will (5), code (5), useful (5), user (5), about (5), has (5), time (5), after (5), request (5), brew (5), cask (5), repository (5), guide (5), feel (4), work (4), decisions (4), technical (4), between (4), public (4), slack (4), ask (4), follow (4), security (4), please (4), 5pm (4), wait (4), being (4), there (4), linux (4), others (4), questions (4), these (4), guidelines (4), maintains (4), free (3), encouraged (3), better (3), issues (3), contributor (3), because (3), off (3), leader (3), users (3), their (3), discussion (3), what (3), two (3), resolved (3), private (3), group (3), must (3), back (3), made (3), good (3), bug (3), fixes (3), would (3), address (3), submitted (3), friday (3), new (3), feature (3), functionality (3), open (3), revert (3), rather (3), wish (3), your (3), pull (3), close (3), case (3), whitespace (3), acceptable (3), don (3), commit (3), macos (3), contributions (3), does (3), help (3), comment (3), see (3), details (3), occur (2), tracker (2), interpersonal (2), ideally (2), decision (2), was (2), who (2), did (2), behaviour (2), contributors (2), given (2), removed (2), upstream (2), remember (2), package (2), doing (2), why (2), means (2), linkable (2), url (2), where (2), move (2), communications (2), something (2), example (2), chance (2), channels (2), version (2), which (2), self (2), left (2), requests (2), usability (2), monday (2), failure (2), etc (2), 24h (2), created (2), themselves (2), passing (2), been (2), opened (2), draft (2), ready (2), stale (2), closed (2), additional (2), standard (2), just (2), making (2), sure (2), still (2), cherry (2), only (2), git (2), also (2), part (2), link (2), tracking (2), improve (2), get (2), enough (2), anyone (2), someone (2), add (2), goal (2), people (2), seek (2), using (2), easy (2), way (2), out (2), non (2), without (2), responsible (2), process (2), avoid (2), whenever (2), need (2), provide (2), addressed (2), based (2), change (2), cookbook (2), documentation (2), pleasantly, disagree, healthy, friendly, disagreement, actively, handled, privately, moderation, insufficiently, documented, explained, clarification, ever, justify, say, alone, topic, discussions, personal, attacks, forbidden, bike, shedding, through, medium, bound, abusive, towards, tolerated, warning, continues, conduct, developer, representative, joins, expecting, distribution, model, long, term, keep, point, encourage, bigger, picture, concerns, discussed, working, makes, easier, along, importantly, appropriate, disclosure, urgent, breakage, needs, necessary, happen, past, end, year, ago, asks, explain, linked, future, direct, messages, imessage, carrier, pigeon, repositories, variety, ways, communicate, each, vast, majority, bumps, once, completed, holiday, vacation, sick, during, leaves, treat, post, feedback, within, period, agreed, reported, immediately, green, thursday, enhancement, existing, bump, improvement, refactoring, give, results, original, less, hour, decide, reverting, carefully, reviewed, status, indicate, yourself, including, note, considered, unless, reopen, closing, corrections, ruby, allowed, fact, opportunity, provided, line, itself, some, kind, modification, careful, inline, patches, apply, amend, pick, remove, commits, our, history, important, blame, allow, bloated, diffs, applies, bodies, explicit, larger, initiative, relevant, isn, yet, create, one, consensus, refer, ticket, context, clear, reading, first, sense, want, wrote, doesn, understand, regressions, suck, 104, report, linking, syntax, sign, picks, amended, ensure, set, username, email, properly, common, gotchas, aims, missing, manager, its, primary, many, while, remaining, maintainable, professional, high, small, volunteers, sensible, features, blend, apple, ecosystems, windows, contained, mission, super, check, branch, cli, checkout, narrow, automatic, workflow, lead, recent, activity, copilot, least, hours, human, weekday, window, sensitive, paths, nearly, impossible, tag, creating, assisted, output, submit, asking, usage, longer, tenure, result, higher, levels, assumed, competence, primarily, measure, catch, bugs, merging, prevent, obvious, account, compromise, broadly, says, unrelated, surprising, such, weakening, sandboxing, boundaries, reviews, quality, learn, otherwise, usually, iterated, waiting, perfect, never, comes, guardrail, absolute, barrier, practical, scrutiny, ceremony, globally, distributed, helps, faster, try, suggestion, edit, how, like, quick, skim, much, leaving, unreviewed, most, valuable, thing, unblock, default, option, relatedly, last, resort, avoided, used, held, agreement, save, personally, had, seems, very, likely, cause, visible, problems, dismiss, fine, else, providing, few, answered, auto, enabled, worry, manually, automatically, even, commented, author, trust, looks, submitting, following, documents, meant, serve, guiding, principles, call, either, from, comfort, previous, burnout, discuss, suggest, prioritise, over, contribute, parts, four, main, teams, tend, overview, maybe, were, looking, formula, special, find, written, here, interesting, definitely, beginner, write, access,

Text of the page (random words):
homebrew documentation maintainer guidelines homebrew documentation maintainer guidelines this guide is for maintainers these special people have write access to homebrew s repository and help merge the contributions of others you may find what is written here interesting but it s definitely not a beginner s guide maybe you were looking for the formula cookbook or cask cookbook overview all homebrew maintainers are encouraged to contribute to all parts of the project but there are four main teams that maintainers tend to be a part of brew maintainers this team maintains the homebrew brew repository see the homebrew brew maintainer guide for more details about being a brew maintainer core maintainers this team maintains the homebrew homebrew core repository see the homebrew homebrew core maintainer guide for more details about being a core maintainer linux maintainers this team maintains the homebrew homebrew core repository on linux cask maintainers this team maintains the homebrew homebrew cask repository see the homebrew homebrew cask maintainer guide for more details about being a cask maintainer these documents are meant to serve as guiding principles as a maintainer you can make a call to either request changes from a contributor or help them out based on their comfort and previous contributions remember as a team we prioritise maintainers over users to avoid burnout if you wish to change or discuss any of the guidelines open a pr to suggest a change reviewing prs when reviewing a pr use approve approve with comments comment or request changes when submitting based on the following guidelines approve if you feel that the pr looks good as is you can approve it as is approve with comments if you have a few questions or comments to be answered and the pr can be merged after they are addressed you can approve with comments please trust that other maintainers will not merge the pr until the comments are addressed rather than e g making them wait another 24h to get another review if auto merge is enabled don t worry prs need to have comments manually resolved before they are automatically merged please feel free to approve or approve with comments even if others have just commented and it will not be merged until the author has resolved the comments ️ comment if you need to ask questions before you can provide a approval but are fine with someone else providing a approval before you provide a comment review and ask questions request changes a last resort when reviewing non maintainers prs this means these changes must be made before this pr should be merged by anyone other maintainers can dismiss this review when these changes have been made when reviewing others maintainers prs this is to be avoided whenever possible save it for if this pr is merged before i personally have had a chance to approve it it seems very likely to cause user visible problems it may be used by the project leader for this functionality is not acceptable in homebrew in that case additional code changes should be held off until there s agreement that the functionality is acceptable relatedly the default option should be to approve with or without comments the most valuable thing a maintainer can do is unblock the work of another maintainer whenever possible you should try to use the github suggestion feature to edit the code how you would like it to be if you only have time for a quick skim that is still much better than leaving the pr unreviewed we re a globally distributed team and this helps us move faster the pr review process is primarily a security measure not a way to catch all bugs before merging the goal is to prevent obvious account or commit compromise does the pr broadly do what it says it does and does it avoid unrelated or surprising changes such as weakening sandboxing or other security boundaries reviews can also improve code quality help maintainers learn and ask useful questions but a pr that is otherwise ready is usually better merged and iterated on than left waiting for the perfect review that never comes the review process is a useful guardrail not an absolute technical barrier so use it to add practical scrutiny rather than ceremony longer tenure as a maintainer should result in higher levels of assumed competence when reviewing prs when reviewing or creating ai assisted contributions follow responsible ai usage you are responsible for the output you submit and must review it before asking others to it is easy to make changes on a pr after approval make follow up prs to address comments or revert prs before a tag it is nearly impossible to merge a pr without approval homebrew brew has a narrow automatic approval workflow for stale non draft lead maintainer prs that have recent maintainer review activity copilot review passing ci at least 48 hours open with no human review a weekday approval window and no changes to sensitive paths using gh pr checkout url is a super easy way to check out a pr branch using the github cli mission homebrew aims to be the missing package manager for macos and linux its primary goal is to be useful to as many people as possible while remaining maintainable to a professional high standard by a small group of volunteers where possible and sensible it should seek to use features of macos to blend in with the macos and apple ecosystems on linux and windows it should seek to be as self contained as possible common gotchas ensure you have set your username and email address properly sign off cherry picks if you amended them use git s if your commit fixes a bug use issue linking syntax e g fixes 104 to close the bug report and link back to the commit add comments it may be enough to refer to an issue ticket but make sure changes and context are clear enough so that anyone reading them for the first time can make sense of them you don t want code you wrote to be removed because the someone new doesn t understand why it s there regressions suck this also applies to issue and pr bodies be as explicit as possible if a pull request is part of a larger initiative link to a relevant tracking issue if there isn t a tracking issue yet create one to improve communication and get consensus don t allow bloated diffs amend a cherry pick to remove commits that are only changes in whitespace they are not acceptable because our history is important and git blame should be useful whitespace corrections to ruby standard etc are allowed in fact this is a good opportunity to do it provided the line itself has some kind of modification that is more than just whitespace changes but be careful about making changes to inline patches make sure they still apply closing issues prs maintainers including the project leader should not close issues or pull requests note a merge is not considered a close in this case opened by other maintainers unless they are stale in which case they can be closed by any maintainer any maintainer is encouraged to reopen a closed issue when they wish to do additional work on the issue any maintainer can merge any pr they have carefully reviewed and is passing ci that has been opened by any other maintainer if you do not wish to have other maintainers merge your prs please use the draft pull request status to indicate that until you re ready to merge it yourself reverting prs any maintainer can revert a pr created by another maintainer after a user submitted issue or ci failure that results the maintainer who created the original pr should be given no less than an hour to fix the issue themselves or decide to revert the pr themselves if they would rather give time for other maintainers to review prs that are an enhancement to existing functionality i e not a fix to an open user issue discussion not a version bump not a security fix not a fix for ci failure a usability improvement a new feature refactoring etc should wait 24h monday to friday before being merged for example a new feature pr submitted at 5pm on thursday should wait until 5pm on friday before it is merged a usability fix pr submitted at 5pm on friday should wait until 5pm on monday before it is merged a user reported issue fix pr can be merged immediately after ci is green if a maintainer is on holiday vacation sick during this time and leaves comments after they are back please treat post merge pr comments and feedback as you would if left within the time period and follow up with another pr to address their requests if agreed the vast majority of homebrew homebrew core prs are bug fixes or version bumps which can be self merged once ci has completed communication maintainers have a variety of ways to communicate with each other homebrew s public repositories on github homebrew s group communications between more than two maintainers on private channels e g github slack homebrew s direct 1 1 messages between two maintainers on private channels e g imessage slack carrier pigeon all communication should ideally occur in public on github where this is not possible or appropriate e g a security disclosure interpersonal issue between two maintainers urgent breakage that needs to be resolved this can move to maintainers private group communication and if necessary 1 1 communication technical decisions should not happen in 1 1 communications but if they do or did in the past they must end up back as something linkable on github for example if a technical decision was made a year ago on slack and another maintainer contributor user asks about it on github that s a good chance to explain it to them and have something that can be linked to in the future this makes it easier for other maintainers contributors and users to follow along with what we re doing and more importantly why we re doing it and means that decisions have a linkable url when an upstream developer or representative joins a discussion remember they may be expecting a distribution model with a long term package maintainer keep the discussion public on github point them to working with homebrew as an upstream project when useful and encourage bigger picture concerns to be discussed in an issue all maintainers and project leader communication through any medium is bound by homebrew s code of conduct abusive behaviour towards other maintainers contributors or users will not be tolerated the maintainer will be given a warning and if their behaviour continues they will be removed as a maintainer maintainers should feel free to pleasantly disagree with the work and decisions of other maintainers healthy friendly technical disagreement between maintainers is actively encouraged and should occur in public on the issue tracker to make the project better interpersonal issues should be handled privately in slack ideally with moderation if work or decisions are insufficiently documented or explained any maintainer or contributor should feel free to ask for clarification no maintainer may ever justify a decision with e g because i say so or it was i who did x alone off topic discussions on the issue tracker bike shedding and personal attacks are forbidden