docs: added a 'Project' site section for contributing and maintenance#2306
docs: added a 'Project' site section for contributing and maintenance#2306JoshuaKGoldberg merged 13 commits intomainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
| Name | Type |
|---|---|
| @flint.fyi/core | Minor |
| @flint.fyi/astro | Patch |
| @flint.fyi/browser | Patch |
| @flint.fyi/cli | Patch |
| @flint.fyi/json-language | Patch |
| @flint.fyi/json | Patch |
| @flint.fyi/jsx | Patch |
| @flint.fyi/markdown-language | Patch |
| @flint.fyi/md | Patch |
| @flint.fyi/next | Patch |
| @flint.fyi/node | Patch |
| @flint.fyi/nuxt | Patch |
| @flint.fyi/package-json | Patch |
| @flint.fyi/performance | Patch |
| @flint.fyi/plugin-flint | Patch |
| @flint.fyi/react | Patch |
| @flint.fyi/rule-tester | Patch |
| @flint.fyi/solid | Patch |
| @flint.fyi/spelling | Patch |
| @flint.fyi/text-language | Patch |
| @flint.fyi/ts | Patch |
| @flint.fyi/typescript-language | Patch |
| @flint.fyi/yaml-language | Patch |
| @flint.fyi/yaml | Patch |
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
| #### Post-Merge Recognition | ||
|
|
||
| Once your PR is merged, if you haven't yet been added to the [_Contributors_ table in the README.md](https://github.com/flint-fyi/flint#contributors) for its [type of contribution](https://allcontributors.org/docs/en/emoji-key "Allcontributors emoji key"), you should be soon. | ||
| Please do ping the maintainer who merged your PR if that doesn't happen within 48 hours - it was likely an oversight on our end! |
There was a problem hiding this comment.
48 hours
This was 24 before. Given JoshuaKGoldberg/all-contributors-for-repository#770 & related issues, I think giving >1 full cycle of daily API throttling resets is probably more reliable.
There was a problem hiding this comment.
sigh this is on my list of issues to file...
michaelfaith
left a comment
michaelfaith
left a comment
There was a problem hiding this comment.
Looks great! Just some minor suggestions for clarity, and removing the (recently removed) lint:packages command. (Request for changes is primarily for the latter)
|
|
||
| If you made it all the way to the end of this page, bravo dear user, we love you. | ||
| Please include an emoji in the bottom of your issues and PRs to signal to us that you did in fact read this file and are trying to conform to it as best as possible. | ||
| ❤️🔥 is a good starter if you're not sure which to use. |
There was a problem hiding this comment.
Am I an awful team member for not remembering to do this? 😬
There was a problem hiding this comment.
I think reviewing this PR (and having always done great with contributing) is more than enough to show you've read the contributing docs 😜
| - For anything _really_ big (e.g. major rearchitectures), wait 5 business days. | ||
| - For anything else: wait 2 business days. | ||
|
|
||
| Use your best judgment and ✨ vibes ✨ interpretation for what category issues and pull requests fall under. |
|
👋 Hi @michaelfaith, thanks for the comment! A scan flagged a concern with it. Could you please take a look? [comment-meaningful] Saying just "✨" doesn't add any new information to the discussion. Replies containing just "+1", "any update?", or other phrases without new information aren't helpful. They cause unnecessary notifications for other contributors and take up space. To resolve this report:
|
|
|
||
| We leave nontrivial issues and pull requests open for some time to give team members a chance to weigh in. | ||
|
|
||
| - For anything clearly good and straightforward (e.g. small typo fixes, reproducible user-facing crashes, trivial dependency bumps, etc.), no waiting period is necessary. |
There was a problem hiding this comment.
To confirm I'm reading (and understanding) this correctly, this category is generally exempt from review above? Obviously if you have any doubt whatsoever don't, but e.g. a #1091-sized fix is fine?
I guess I want some clear definition of "nontrivial" above 🤷🏻♂️
(And, to be clear, now that it's not just Josh, Auvred, and I it's effectively never a big deal to wait, so I'd be happy just striking the nontrivial clause, probably with an exception for Josh-Amp rule PRs and #1906-level breakage.)
And really this is the wrong section to attach this comment to but too late oh well.
There was a problem hiding this comment.
To confirm
👍
#1091-sized fix is fine?
👍
clear definition of "nontrivial"
...I can't think of one 🤔 😬 .
striking the nontrivial clause
Oh that's interesting. Maybe let's see how it goes? Sometimes it's really nice to have quick docs fixes / bugs land. Especially for the recent things that have inconvenienced us, like the cspell rule issues.
There was a problem hiding this comment.
Examples of trivial change that would be a bit lame to have to wait on:
- update a dependency version
- oops I made a typo in a README that nobody caught in review, let me fix that real quick
- pnpm lock has gotten a bit messy, let me
pnpm dedupe
I'm also ok, drawing a hard line and just waiting, but if we consider the above kinds of things the "trivial" bar, then vibes-based also works for me.
Should we also have an exception for critical issues like fixing failing main builds due to a bad merge?
There was a problem hiding this comment.
Should we also have an exception for critical issues like fixing failing main builds due to a bad merge?
100% yes.
Examples of trivial change that would be a bit lame to have to wait on
Yeah, agreed there. As much as it feels like there's a security issue there for deps specifically, renovates automerging anyway, it really doesn't make a difference. 👍🏻
In other words, vibes is fine by me I guess 👍🏻
|
|
||
| ## Waiting Periods | ||
|
|
||
| We leave nontrivial issues and pull requests open for some time to give team members a chance to weigh in. |
There was a problem hiding this comment.
Oh, and is this since last review, since the PR was opened, since Josh was last active, since I ran out of AI credits, or since the last full moon? 🙃 (I'm guessing the first, but then see below ↓)
How does this work with the primarily self-merging system?
There was a problem hiding this comment.
Ooh good clarification point. Let's say: since the last significant change (also measured by ✨ vibes ✨)? That's what we've done in typescript-eslint and has felt good to me.
There was a problem hiding this comment.
Sorry to keep pushing this and maybe I'm being a bit dull, but by "significant change" I'm assuming that means responding to reviews isn't significant unless the reviews encouraged you to reapproach it? AKA ✨Vibes✨ again?
|
Re the OctoGuide comment: lol. octoguide/bot#449 |
michaelfaith
left a comment
michaelfaith
left a comment
There was a problem hiding this comment.
Adding one more piece of feedback, now that we've landed on a standard for changesets (#2298)
Co-authored-by: michael faith <[email protected]> Co-authored-by: Eli <[email protected]>
There was a problem hiding this comment.
This is almost exactly copied from https://typescript-eslint.io/contributing/ai-policy, shoutout @kirkwaiblinger (typescript-eslint/typescript-eslint#11836)
michaelfaith
added
1 approval
3 participants
PR Checklist
status: accepting prsOverview
Moves content from the following
.github/*.mdpages into the site to be more discoverable:.github/CODE_OF_CONDUCT.md->/project/code-of-conduct.github/Contributing.md->/project/contributing.github/Development.md->/project/developmentAdds a new
/project/maintenancepage that summarizes #1242:status: in discussionuntil they're instatus: accepting prsThis intentionally leaves me (Project Lead) out of requirements for anything, as things shouldn't be blocked on me at all.
Also adds an FAQ about getting involved that points at Contributing.
Is there anything else we should add in?
❤️🔥