Commit Messages are about Intent. They should answer “why is this here” in as many ways as you can describe.
On Twitter this morning, I asked: How do you feel about having clients sponsor development of specific features? Good idea or fraught w/ problems?
Apparently this dilemma resonates with developers:
- Rarst: “sounds better in theory than works in practice, from my limited experience”
- Boone: “Generally a good idea, as long as the client’s needs aren’t so wacky as to make the feature awkward for general release. You might also include something in the agreement about post-contract support of the feature. Transition from ‘I’m paying you to implement my wishes’ to ‘I’m a regular user making feature requests’ is the tricky point”
- Eric: “If you properly vet these specific features (as opposed to blindly accepting cash) I think it’s a good idea. Biggest drawback is when the sponsorship dries up and you still have to support said feature in the plugin.”
- Brad: “great idea, not only features but full plugins. Easy to sell them on it knowing you’ll keep it up-to-date with current WP”
- Brady: “I’d say it’s a great route if the feature makes sense for general use, otherwise an extension/add-on might be better.”
- David: “good idea, as long as client understands the difference between customization and configuration. Oh, and proper contracts.”
- Nick: “As long as they understand they don’t own that feature and you may need to implement it in a more general way, it can work. One approach is to make it an addon and add the necessary hooks in core plugin. Allows you to EOL the feature if needed.”
- George: “don’t see anything bad in developing add-ons for side income, plus you might never developed for your use.”
- Jake: “as others said, it’s all about good expectations upfront, and not compromising the rest of the plugin’s audience”
- Travis: “Personally, I think it is a win-win, but it heavily depends on the “strings attached” mentality of the sponsor.”
- Ryan: “I’ve done that many times before and have encouraged it. I usually gave a big discount for open source stuff. I used to provide two prices, one for open source, one for closed source. Everyone chose the cheapest option.”
- Make sure you’re explicit about the business relationship upfront (including support scope), probably in contract. If you aren’t, it can get complicated.
- If it fits within the scope / roadmap of the plugin, it can be a nice way to bootstrap open source development. Otherwise, it probably makes sense as an add-on.
- Pay attention to what users want as add-ons, as you can potentially turn those into premium plugins.
Advantages of pre-deploy code review, over post-deploy audit:
- Authors have a strong incentive to craft small, well-formed changes that will be readily understood, to explain them adequately, and to provide appropriate test plans, test coverage and context.
- Reviewers have a real opportunity to make significant suggestions about architecture or approach in review. These suggestions are less attractive to adopt from audit, and may be much more difficult to adopt if significant time has passed between push and audit.
- Authors have a strong incentive to fix problems and respond to feedback received during review, because it blocks them. Authors have a much weaker incentive to address problems raised during audit.
- Authors can ask reviewers to apply and verify fixes before they are pushed.
- Authors can easily pursue feedback early, and get course corrections on approach or direction.
- Reviewers are better prepared to support a given change once it is in production, having already had a chance to become familiar with and reason through the code.
- Reviewers are able to catch problems which automated tests may have difficulty detecting. For example, human reviewers are able to reason about performance problems that tests can easily miss because they run on small datasets and stub out service calls.
- Communicating about changes before they happen generally leads to better preparation for their effects.
Enlightenment is knowing what your code is doing and why. Thankfully, instead of having to depend on your inner calm, there are a number of tools and strategies you can use to better see what’s going on. We’ll survey a range of topics you should explore to turn your frustration into bliss.
Feeling better already? In this session, we’ll touch on everything from debugging to best practices to coding standards to version control to performance and optimization. You’ll hear the insights WordPress.com VIP shares every day.
Session notes are below the slides.