Perhaps you are unfamiliar with the term "dogfooding", in short it is the idea that a company or organization use its own Product or Service in addition to providing it to the others. A more complete definition can be found on Wikipedia under Eating your own dog food.
The reasons a group might chose to dogfood are varied, but an important reason is to ensure that they are familiar with the challenges with using the good or service, or to put it in business jargon... they want to find opportunities to make, what they make, better.
For groups that are just starting to do this it can be EYE OPENING what their customers/patrons are dealing with to use their stuff. Often the overall impact is great and everybody wins. So why not do this for policies within, let's say an IT organization. How would one go about dogfooding a policy you may ask? Thanks for asking... let me tell ya what I think.
For any organization to be successful there needs to be consistency in the way it approaches work. This is especially true for IT groups. The term consistent and repeatable is often spoken when discussing how to approach various aspects of the IT assembly line. At times the way to achieve this goal is to determine a policy that governs the way IT associates do their work. Examples of this could be found in policies about documenting changes, how to request access to a system. You can see this even outside of IT, such as when a communications department issues a corporate policy on how to setup your e-mail signatures.
So back to the point I was making, it can be of GREAT benefit if the ones making the policy are sure to follow their own policy to ensure they are not creating any undo burden on those that the policy is enforced on. This can best be illustrated with a concrete example. Let's look at having a source code repository based on the GIT system with a Pull Request policy...
Now, most GIT systems have the concept of a branch policy that permits the owner to require a Pull Request to merge changes along with some level of approvers and perhaps even all comments to be resolved and a CI build to complete successful. If the corporate policy is to have this as the branch policy it stands to reason that even repos for the said owners should also have this policy. So why wouldn't they?
This is why a slippery slope mindset can occur and what can wind up causing groups to NOT dogfood their own policy. Further along our example, the policy maker has a repo which only he uses, so no reason to have a PR model, right I mean who is going to approve it if he's the only one working on the repo? This is where the real benefit of dogfooding the policy comes into play. Right off the bat it will require the policy maker to grasp the need of doing one of two things.
The first option would be to create an addendum to the policy which lifts the branch policy in terms of self review or having any reviews at all, but perhaps they still need to create a CI build which would again be ideal and help ensure the intent of the policy stick, i.e. that the intent of the policy is to have repos which are of high quality and the CI build on the PR prevents the master branch from being in a "unbuildable" state.
The second option, and the one I personally prefer, the policy owner would need to invite someone into the repo to do reviews thus further ensuring that policy is more fully adopted.
So if you find yourself in a position of setting policy it is helpful for all involved, including you dear policy maker, to adhere to the policy yourself.
Top comments (0)