as open source maintainer:
I like normal "Merge" the most.
- It keeps git history of the author.
- It works great when multiple authors work on a PR.
- git blame shows a smaller commit. More likely to understand what's the change intent.
- git bisect finds bugs easier.
- Easier to remove a part of the PR.
Author should feel free to squash logical related commits in her/his PR.
- You lose information.
- Difficult to fix a PR based this PR or a intermediate state of it.
- You rewrite commits.
- Difficult to fix a PR based this PR or a intermediate state of it.
I don't like to have commit messages in a specific format.
- It should be easy to write the message.
- A PR author probably don't know how about your format.
- Asking her/him to rewrite the commit message could be difficult. Not everybody is a git expert.
- Commit message can't be wrong, because it's not relevant for the process
- You don't need an extra tool to make a commit
- Relevant information can be put into the PR. It's easily editable and can have a template. It also includes discussion.
- Minimium work required to write and merge PRs.
I like github reviews.
I don't think an extra tooling is needed here.
I don't like to use a separate tool for releasing.
I like this command: npm version patch && git push && git push --tags && npm publish
- It's simple. No setup needed. Works on every repo.
- It creates tags in git and npm.
- It fails if your local branch is not up-to-date.
- It fails if you have uncommited changes.
- You can manually fix-up every part of the process. Custom version, npm tag, etc.
- You have to check CI manually before cutting a release. But probably you already have a notification in place if CI on master fails.
I don't like automatic publish to npm.
I think it's not nessecary (at least for npm packages).
Just use webpack/webpack#master in your package.json dependencies to get the bleeding edge version.
I don't like to leak my npm credentials to github or travis.
I like to publish static sites automatically to gh-pages.
I think it's only relevant if you expect many commits.
I like to write the change manually.
I don't like a CHANGELOG.md file.
I like github releases.
I like to write the changelog in one go.
- You can omit unimportant messages
- You can merge multiple commits (i. e. a PR fixing another PR)
- You can add details to important stuff, i. e. steps for migration, links to documentation
- You can edit the changelog if there was a typo in it
- You don't have to rewrite git history to fix the changelog
- Less context switching for interleaving changelog writing with coding. Only changelog work on release.
- Fewest duplications
- CHANGELOG.md would duplicate github releases
- generating changelog from git history would duplicate git history in changelog
- Details history: git history
- Summarized changelog: github releases
I like integration tests over unit tests.
- You get more for your time!
- Refactoring is easier.
- While refactoring it's less likely that you have to change the tests.
- It's more likely to write correct integration tests than unit tests.
- Integration tests can be used as examples for users.
I think they are useless.
I like using labels and milestones instead.
- Too many clicks
- Duplicated information
I don't like to add many labels.
If issues have more the 3 labels I think that something is wrong. Remove labels!
In my opinion most useful labels:
bugit's a bugmerge itPR is fine, could be merged if CI passesbreaking changePR that as breaking changestests neededPR that need tests- Label for PRs another Contributor should take care of
- Labels for issue where everybody can do a PR (easy one)
I like to assign important issues to the next milestone.
I like to assign important PRs to the next milestone.
I like to close issue if issue template is ignored.
I don't like trying to solve problems when information is incomplete.
I don't like to answer questions that many other people could answer. -> Stack Overflow
I don't like to write node.js code that need to be transpiled before use.
- Extra step, extra source of errors
- Slows down development
- Debugging is more diffcult
- Coverage is more difficult
- People that want to contribute may not know your transpiled language
- Don't assume everybody knows or likes Typescript or ES2021
It's fine if you need to bundle anyway, i. e. when writing code for the browser.
I like CI.
- Travis is great to linux test and general tests
- Travis is slow for OSX build. Don't do more than 1 OSX build per commit.
- Configure travis to only build master branch and PRs to reduce travis load.
- Appveyor is great to Windows test. But it's also slow, because it only does one build at a time. Not as slow as travis for OSX.
- Configure appveyor to only build master branch and PRs to reduce appveyor load.
- CircleCI cannot replace travis, because it doesn't support matrix builds.
- CircleCI can be used to fast feedback for PRs.
I think people don't read CI results for their PRs.
I like to copy relevant CI log seqment into the PR comments.
I like code coverage.
- codecov.io great, very detailed info
- Can be configured to require 90% coverage on PR diffs
- coveralls.io great, less detailed but fine
- It breaks when doing too many builds in short time (you get no result)
I don't like github teams.
I like contributors on the repo settings.
I like teams only if they affect multiple repos that are connected.
I like if only one person is responsible for release and publish.
I like to assign only one person for merging PRs. (not always possible)
- Teams need too many click to configure for each repo
- Similar structure of repos and teams is an antipattern
- Teams can't be moved between orgs
I like to enable master as protected branch.
I like required status checks: travis, appveyor, coverage (patch > 90%).
Note: If it is also enforced for admins your can't push a new release commit
I like to disable "Squash to merge" and "Rebase to merge".
I like this gist.
(But writing Node v4 compatible JS sucks. I transpile/bundle for the server as well, gets me a nice and fast bundle to run - faster start time.)