Project development methodology (was chef#4529 and chef-solo)

tldr; a debate emerged over a tiny feature as to whether feature parity between chef-client and chef-solo was a requirement, with the goal of improving the user experience for all users through consistency.

I’m wondering what the projects beliefs are exactly and why we haven’t written them down. It sounds like a barn shaped shed of a project.

As we move further toward Release Early Release Often RERO and we worry about convincing users of it’s value, the same lack of value statement emerges.

Yet we’ve somehow muddled along with many implied beliefs in the contribution process.

  • Yes, you must sign a CLA. Usually.
  • Unit tests are required except when they’re impossible.
  • Integration tests are desired, except we haven’t had a framework since cucumber, until the last couple weeks.
  • No promises about your rare platform.

The roadmap (how to get your feature/bug written/fixed)

  1. Do it yourself, scratch that itch.
  2. Give money to someone who will do it for you.
  3. Stick to common platforms and use cases, get lucky.

At Chef Software, some teams have been writing more Minimum Viable Products and collecting feedback, creating a tighter iteration loop. Don’t write a feature you don’t have a customer use case for. Like “don’t worry about scalability, you don’t need it yet.”

Some late night [for me these days] thoughts:

  • How far out do we need to plan/design? What are the consequences on contributions? What projects does chef-rfc apply to?
  • Must chef-solo have feature parity with chef-client? If only for non-server related features, must local-mode have feature parity with chef-client for all features? knife bootstrap and knife-windows? resources for all tier 1 platforms?
  • Should we have more clear guidelines, or rely on beliefs of the individual project maintainers through up/down votes?

Anyone want to take a stab at narrating the projects beliefs?