You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thank you for the project. I'm a Publii user and a maintainer on some JS open-source and closed-source production projects with many workflows and integrations.
I noticed there are a large number of open GitHub issues and wanted to share some changes from my other projects over the past year that helped improve feature velocity and reduce recurring manual effort when accepting PRs and cutting releases:
Added Playwright end-to-end tests, sometimes combined with nock, to quickly detect when a change breaks the app. Once the test harness was in place and we had created separate help-wanted GitHub issues, getting the test suit to have good coverage happened by contributions from the community. With the tests in place, we also adjusted our GitHub workflows to not only check incoming PRs, but also auto-merge Dependabot PRs that are passing the tests.
Enabled GitHub Copilot automatic code reviews (Copilot Pro is free for open-source maintainers) as an initial review pass for early PR iterations. I usually just verify that its feedback is aligned with my intended design choices and comment if any of its feedback can be ignored/skipped, before asking the PR submitter to address the automated review feedback.
Added a git pre-push hook to run lint and tests, so broken code can't be pushed and eventually end up in PRs.
Added a PR template with a checklist asking contributors to confirm manual testing, adding/updating tests and documentation for their change, and that existing unit and recorded E2E tests were run and were not bypassed.
I think Publii could benefit from a similar approach to reduce maintainer load over time and make it easier for the community to contribute more effectively.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
First, thank you for the project. I'm a Publii user and a maintainer on some JS open-source and closed-source production projects with many workflows and integrations.
I noticed there are a large number of open GitHub issues and wanted to share some changes from my other projects over the past year that helped improve feature velocity and reduce recurring manual effort when accepting PRs and cutting releases:
Added Playwright end-to-end tests, sometimes combined with nock, to quickly detect when a change breaks the app. Once the test harness was in place and we had created separate help-wanted GitHub issues, getting the test suit to have good coverage happened by contributions from the community. With the tests in place, we also adjusted our GitHub workflows to not only check incoming PRs, but also auto-merge Dependabot PRs that are passing the tests.
Enabled GitHub Copilot automatic code reviews (Copilot Pro is free for open-source maintainers) as an initial review pass for early PR iterations. I usually just verify that its feedback is aligned with my intended design choices and comment if any of its feedback can be ignored/skipped, before asking the PR submitter to address the automated review feedback.
Added a git pre-push hook to run lint and tests, so broken code can't be pushed and eventually end up in PRs.
Added a PR template with a checklist asking contributors to confirm manual testing, adding/updating tests and documentation for their change, and that existing unit and recorded E2E tests were run and were not bypassed.
I think Publii could benefit from a similar approach to reduce maintainer load over time and make it easier for the community to contribute more effectively.
Beta Was this translation helpful? Give feedback.
All reactions